BorlandTalk.com

Ivo Tops · Guest

The MM B&V tool should really have a test that uses over a 100 threads.
Several server applications at my work use a couple of hundred threads
so the number is not unrealistic. During our selection of a memory
manager we found out some MM's are not equipped for that amount of threads.

I know for certain that MultiMM has two crashing bugs of which one is
very likely to show up only after you reach a 100 threads.

I don't mind writing the test, but are additions in code to the tool
accepted from biased memory manager authors? <big smile>

Kind regards,

Ivo Tops

Pierre le Riche · Guest

Hi Ivo,

Pierre le Riche · Guest

Hi Again,

Robert Houdart · Guest

"Ivo Tops" wrote in message...

Martin James · Guest

Robert Houdart · Guest

Hi Pierre,
Please, no more reallocation benchmarks Smile

And if you really want more, I would prefer them slightly more "real-world".

As said before, I do not care about winning the contest, I simply want us to
finish with the very best MM. It would be foolish to adapt some of the
parameters in our respective MM to perform better in farfetched benchmarks,
but less well in real-world applications. That would beat the whole purpose
of the challenge...

Robert

Fredrik Lysholm · Guest

I agree.. if this is something you feel some MMs would fail then I'd rather
see it as a part of the validation..

Just another crazy idea... I've noticed that some MMs perform worse after a
while.. why not add a set of "pre-benchmark" functions that tries to
screw-up the MM? The mentioned re-allocation tests in a multithread
enviroment could quallify as one of those.. (or simply always require the
benchmark to run ones before we actully start counting..)

// Fredrik

"Robert Houdart" <robert (AT) elinksuite (DOT) com> wrote

Pierre le Riche · Guest

Hi Robert,

Robert Houdart · Guest

Hello Pierre,

I'm glad to have the opportunity to explain the background of the choices in
BucketMM. Sorry for the length of the answer...

First of all, for the benefit of others less familiar with BucketMM, let me
explain what BucketMM does:
1) if you upsize a block smaller than 256 bytes, it will upsize by at least
64 bytes
2) it never downsizes blocks smaller than 256 bytes

A crucial question is: when does Delphi perform downsizing/upsizing of
blocks smaller than 256 bytes ? IME this is nearly always related to string
manipulation.

Most Delphi developers tend to be rather careless about string
manipulations. They're not aware that in the following loop they call the
Realloc function 256 times:

aString:='';
for j := 1 to 256 do
aString := aString + 'A';

This is poorly performing code. Much better is:

SetLength(aString, 256);
for j := 1 to 256 do
aString[j] := 'A';

with just a single call to GetMem and performance maybe 100 times better
than the previous with the standard RTL MM.

The goal of BucketMM is to reduce the performance penalty for the first
code.
In fact, with BucketMM you get pretty close to the pre-Delphi 4 situation
with static ShortStrings of 256 bytes instead of AnsiStrings. So you combine
the reference-counted AnsiStrings with the pre-Delphi 4 performance of the
ShortStrings.
Furthermore, most dynamically constructed strings are rather short-lived, so
the memory overhead remains fully acceptable.

I feel that in most real-world applications made by Delphi developers, the
BucketMM choices are very sound, improving the performance and having little
impact on the overall memory consumption.
On the other hand, I have difficulty in seeing how you could, in a normal
Delphi application, come close to a situation in which systematically a
252-byte block is allocated and then downsized to 1 byte, or, a 1-byte block
is allocated and then upsized to 13 bytes.
Of course, the BucketMM parameters could easily be adapted to this kind of
benchmark, but if this situation never happens in a normal Delphi
application, what's the point ?

If you feel BucketMM is taking undue advantage of this feature in the
benchmark results, you're absolutely right. There are too many realloc
benchmarks, and I try to remedy the situation by adding non-realloc
benchmarks and starting a hopefully long series of Replay Benchmarks. If we
end up with between 10 and 20 replay benchmarks on real applications, they
will clearly tell us which approach is best.

In the meanwhile, you might consider adopting the same strategy in FastMM.
It would be interesting to see the results of that...

Kind regards,
Robert

Martin James · Guest

Pierre le Riche · Guest

Hi Robert,

Robert Houdart · Guest

Hello Pierre,

Your answer clearly illustrates the point that it may not be possible to
find a single MM that will prove the very best for each and every
application.

The virtual treeview is a good example of small block resizing that is not
related to string manipulations, I now understand your benchmark much
better. For this case, the BucketMM settings will indeed have you using more
memory than would really be required.

On the other hand, the performance improvement on the NexusDB benchmarks
shows you something which is also quite real-world. I do expect a lot of
Delphi applications to contain some awkward string construction code that
benefit from the BucketMM settings.

So what's the right balance ?
We could both very easily implement the choice of downsize limit of 32 or
256 bytes and upsize increase of 25% or 25% + 64 bytes by means of a
conditional define.
Problem is we're going to end up with a bunch of compiler directives that
nobody will ever use for the simple reason they would not be aware of the
issue.

Could we provide the MM with some intelligence of its own to adapt its
behaviour to the demands ?
One idea is to store a realloc count for each memory block. As long as the
realloc count is smaller than, say, 4, the MM could return the exact number
of bytes. Above that point, the MM might add some intelligence to anticipate
future reallocations.

Thanks for the discussion,
Robert

Robert Houdart · Guest

Pierre le Riche · Guest

Hi Robert,

Robert Houdart · Guest

Hello Pierre,

1) Please read Martin James's reply on my original post. He strongly agrees
that the 256 byte downsize feature aims at a design flaw of the Delphi
AnsiString implementation. I have literally seen hundreds of code examples
of people both inside and outside my company to know that this issue is
real.

2) Once again, I'm more interested in real-world applications than in the
benchmarks.
I made the ReallocCount development because it seemed like an original idea
that might give some improvement for real-world applications. It was btw
triggered by our discussion.
At this point it's an experimental feature of which I hope it will make a
difference in some of the replay benchmarks. If it does not, it will
probably disappear. On the other hand, if it does improve performance on the
real-world replays, surely we should keep it ?
Ultimately it's the real-world applications that will decide, not the small
virtual world of MM benchmarks. So if everybody helps to get some real-world
replay benchmarks, we will soon have better arguments to evaluate new
features...

3) Please feel free to adopt the same ideas/techniques/algorithms.
Everything is open-source, plainly visible to everybody. If some
ideas/techniques are bad, our benchmarks should tell us ! If some are good,
likewise !

4) If you do not feel happy with the NexusDB Benchmark, let's change it so
it is no longer a reallocation benchmark and no longer relies so heavily on
System.Move.

5) Please feel free to adapt your benchmark in the way you describe.

6) I do not share the philisophy that our goal should be to expose
weaknesses in other MM's. The danger is that one creates benchmarks that
have no significance outside the little theatre of the Fastcode challenge.
I prefer to create benchmarks with the focus on similarity with real
applications. If the MM happens to perform badly, great, it's an opportunity
to learn and to improve the algorithm. This was initially the case with my
own "Raw Performance" benchmarks, which has learned me a lot.

Kind regards,
Robert