Don't duplicate questions. Answered in the other thread.Your answer is not clear for me.
My guess? To make it a fairer comparison. Read the intro at "Free Pascal versus C++ g++ fastest programs (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fpascal-gpp.html)"
"measuring the quality of the generated code when both compilers are presented with what amounts to the same program."
These are only the fastest programs.
I want clear answer.That is a benchmark game, and since FPC has a choice with memory managers author probably tried them all and left the faster one.
Why CMem is the faster one?I want clear answer.That is a benchmark game, and since FPC has a choice with memory managers author probably tried them all and left the faster one.
Because cmem seems faster in multithreaded applications (by much) whereas there is no noticable difference with heap.inc in single threaded apps.https://github.com/graemeg/freepascal/blob/master/rtl/inc/cmem.pp
At least on windows.
Why do you refer to a fork instead of the real code available from freepascal.org? It is the exact same and usually more current.
Why https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-fpascal-7.html uses CMem memory manager?
Some raw numbers, from TestSQL3 string allocation tests (single threaded):
- FPC default heap
500000 interning 8 KB in 77.34ms i.e. 6,464,959/s, aver. 0us, 98.6 MB/s
500000 direct 7.6 MB in 100.73ms i.e. 4,963,518/s, aver. 0us, 75.7 MB/s
- glibc 2.23
500000 interning 8 KB in 76.06ms i.e. 6,573,152/s, aver. 0us, 100.2 MB/s
500000 direct 7.6 MB in 36.64ms i.e. 13,645,915/s, aver. 0us, 208.2 MB/s
- jemalloc 3.6
500000 interning 8 KB in 78.60ms i.e. 6,361,323/s, aver. 0us, 97 MB/s
500000 direct 7.6 MB in 58.08ms i.e. 8,608,667/s, aver. 0us, 131.3 MB/s
- Intel TBB 4.4
500000 interning 8 KB in 61.96ms i.e. 8,068,810/s, aver. 0us, 123.1 MB/s
500000 direct 7.6 MB in 36.46ms i.e. 13,711,402/s, aver. 0us, 209.2 MB/s
for multi-threaded process, we observed best scaling with TBB on this system
BUT memory consumption raised to 60 more space (gblic=2.6GB vs TBB=170GB)!
-> so for serious server work, glibc (FPC_SYNCMEM) sounds the best candidate
Unfortunately they didn't published the results for the multi-threaded tests afaik. Xeon E5-2543v2 2*CPU i7-7700K CPU
(allocated 20 logical (8 logical threads,
threads, 10 physical 4 physical cores),
cores, NUMA), AVX-1 AVX-2
Orig. AVX-br. Ratio Orig. AVX-br. Ratio
------ ----- ------ ----- ----- ------
02-threads realloc 96552 59951 62.09% 65213 49471 75.86%
04-threads realloc 97998 39494 40.30% 64402 47714 74.09%
08-threads realloc 98325 33743 34.32% 64796 58754 90.68%
16-threads realloc 116273 45161 38.84% 70722 60293 85.25%
31-threads realloc 122528 53616 43.76% 70939 62962 88.76%
64-threads realloc 137661 54330 39.47% 73696 64824 87.96%
NexusDB 02 threads 122846 90380 73.72% 79479 66153 83.23%
NexusDB 04 threads 122131 53103 43.77% 69183 43001 62.16%
NexusDB 08 threads 124419 40914 32.88% 64977 33609 51.72%
NexusDB 12 threads 181239 55818 30.80% 83983 44658 53.18%
NexusDB 16 threads 135211 62044 43.61% 59917 32463 54.18%
NexusDB 31 threads 134815 48132 33.46% 54686 31184 57.02%
NexusDB 64 threads 187094 57672 30.25% 63089 41955 66.50%
Xeon E5-2667v4 2*CPU i9-7900X CPU
(allocated 32 logical (20 logical threads,
threads, 16 physical 10 physical cores),
cores, NUMA), AVX-2 AVX-512
Orig. AVX-br. Ratio Orig. AVX-br. Ratio
------ ----- ------ ----- ----- ------
02-threads realloc 80544 60025 74.52% 66100 55854 84.50%
04-threads realloc 80751 47743 59.12% 64772 40213 62.08%
08-threads realloc 82645 32691 39.56% 62246 27056 43.47%
12-threads realloc 89951 43270 48.10% 65456 25853 39.50%
16-threads realloc 95729 56571 59.10% 67513 27058 40.08%
31-threads realloc 109099 97290 89.18% 63180 28408 44.96%
64-threads realloc 118589 104230 87.89% 57974 28951 49.94%
NexusDB 01 thread 160100 121961 76.18% 93341 95807 102.64%
NexusDB 02 threads 115447 78339 67.86% 77034 70056 90.94%
NexusDB 04 threads 107851 49403 45.81% 73162 50039 68.39%
NexusDB 08 threads 111490 36675 32.90% 70672 42116 59.59%
NexusDB 12 threads 148148 46608 31.46% 92693 53900 58.15%
NexusDB 16 threads 111041 38461 34.64% 66549 37317 56.07%
NexusDB 31 threads 123496 44232 35.82% 62552 34150 54.60%
NexusDB 64 threads 179924 62414 34.69% 83914 42915 51.14%
I find this article and ensuing discussion pretty interesting on the relative nature of memory allocator performance.+1.
r42713 florian 2019-08-16 22:47:37 +0200 (Fri, 16 Aug 2019)
+ make use of the mremap syscall of linux to re-allocate large memory blocks faster
Commit consists out of 1 line
M /trunk/rtl/inc/heap.inc
M /trunk/rtl/linux/ossysc.inc
M /trunk/rtl/unix/sysheap.inc
A /trunk/tests/test/theap2.pp
Yes. Then again I ran into the problem that in FPC we have to maintain and store size, otherwise Lazarus crashes..... Which is silly.
That slows down our memory manager considerably. The size can on many platforms be obtained elsewhere:
- windows _memsize
- linux & bsd malloc_usable_size
_msize Marco, https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/msize?view=vs-2019 Sorry. That is the windows equivalent.
I did not write the correct call but for the major platforms it is not needed to keep size (Win, apple, linux, bsd all have a call that does the same)
You confuse the lowest level: the OS.
Delphi doesn't keep size. (not the first time I mentioned it.....like 8 years ago)
It is a major hinder to improve the FPC memory manager: too much housekeeping on top.
Yes. Then again I ran into the problem that in FPC we have to maintain and store size, otherwise Lazarus crashes..... Which is silly.How do you come to that conclusion? FPC does not enforce that all, you just need to make sure that your implementation of the functions of TMemoryManager behave correctly. And if Lazarus (or some package of it) should depend on the internal workings of the memory manager (e.g. by assuming a size field in front of the allocated block) then that is a bug and should be reported.
That slows down our memory manager considerably. The size can on many platforms be obtained elsewhere:
- windows _memsize
- linux & bsd malloc_usable_size
This behavior is also documented, although obfuscated (freemem remark) https://forum.lazarus.freepascal.org/index.php?action=post;topic=46420.15;last_msg=331064I'm sure your link is wrong %)
Actually, I would recommend to move the declarations to the implementation section just because of that!Fix it in Lazarus code? ;)
Problem: Lazarus people: And now what??????????
@PascalDragonFirst of your link is wrong. I assume you meant this (https://www.freepascal.org/docs-html/current/prog/progsu175.html)?
In general, but focussing on cmem:
If you leave out the size, Lazarus doesn't work - but Fpc does! -. Try it yourself using cmem as a template, simply rip out the silly size management.
So Lazarus relies on implementation detail.
This behavior is also documented, although obfuscated (freemem remark) https://forum.lazarus.freepascal.org/index.php?action=post;topic=46420.15;last_msg=331064
The "should" should be replaced with "must" but only for Lazarus.
(Actually I think this is quite a substantial bug in Lazarus)
It is enough to move the declarations from interface to implementation. (These should not have any use there whatever any memory manager implementation)What declarations? Those of TMemoryManager and its function variables? No. Those must be in the interface section, because they are needed to be used from other units, namely to implement memory managers.
Actually, I would recommend to move the declarations to the implementation section just because of that!
Problem: Lazarus people: And now what??????????Report a bug with them.
what happens when I increment that pointer? Now its no longer at its original starting point..For a number of reasons, performance among them, most memory managers require the original pointer they returned to free the memory block.
For all Hero, a bit request from batalion of newbie :)Single source cross platform compatibility in mind, otherwise you have to change the uses clause everytime you change target platform. Some of us, like me, uses the build mode to build binaries for multiple platform in a single click, it won't work if I have to do what I said earlier, nor it will be a pleasing experience having blocks of ifdef for every platform.
program Project1;
{$mode objfpc}
{$h+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads} // why in each program have to declare like this
cthreads,
{$ENDIF}{$ENDIF}
is there a way for platform specific likeFirst, it's completely the opposite of the above principle. Second, it cannot be done so. Not all (Unix targeting) programs require threads, so it can't be forced so (since not just unnecessary, but including cthreads pull a significant dependency to the binary size). Directives work at compile time, hence it cannot be included in a compiled unit. Or do you prefer FpcWindows, FpcUnixNoThreads, FpcUnixWithThreads, etc.? It's a big NAH from me, both from users POV and maintainers POV.
program Project1;
uses FpcWindows or DelphiWindows ...
program Project1;
uses FpcLinux or DelphiLinux ...
and all CMem, CThreads, directives, etc are handle seamlessly?
I was thinking on the lines of it keeping an ADDRESS reference to the pointer variable itself.what happens when I increment that pointer? Now its no longer at its original starting point..For a number of reasons, performance among them, most memory managers require the original pointer they returned to free the memory block.
With most memory managers, passing a pointer that points somewhere within an allocated memory block rarely, if ever, yields a desirable result.
I was thinking on the lines of it keeping an ADDRESS reference to the pointer variable itself.What you described sounds like how Windows 16bit managed memory. GlobalAlloc and LocalAlloc returned a pointer to a pointer, this second pointer being the actual pointer to the memory block. This is what allowed Win16 to move memory blocks. Whenever it moved a block, usually to lower heap fragmentation, it would update that second pointer.
by giving the pointer via reference back to a memory handler to release it, it can then scan a table of allocated chunks to locate a matching reference to a pointer.
This way the pointer itself can change value but the entity will always be the same.
Which means of course if you make one pointer := another, the pointer can not be used to release memory from the "another" pointer.
I personally think that performance is more important than the "inconvenience" to keep the original pointer, which the memory function returned to me, around.I was thinking on the lines of it keeping an ADDRESS reference to the pointer variable itself.what happens when I increment that pointer? Now its no longer at its original starting point..For a number of reasons, performance among them, most memory managers require the original pointer they returned to free the memory block.
With most memory managers, passing a pointer that points somewhere within an allocated memory block rarely, if ever, yields a desirable result.
by giving the pointer via reference back to a memory handler to release it, it can then scan a table of allocated chunks to locate a matching reference to a pointer.
This way the pointer itself can change value but the entity will always be the same.
Which means of course if you make one pointer := another, the pointer can not be used to release memory from the "another" pointer.
@PascalDragonSo Lazarus relies on implementation detail.
In general, but focussing on cmem:
If you leave out the size, Lazarus doesn't work - but Fpc does! -. Try it yourself using cmem as a template, simply rip out the silly size management.
2° Usage of MemoryManager.memsize :I don't know what is failing, I have not tried. It could even be that it's not MemSize that is the problem, but that some code tries to simply access the hidden size field. Either Thaddy has more info or you could play around with it yourself.@PascalDragonSo Lazarus relies on implementation detail.
In general, but focussing on cmem:
If you leave out the size, Lazarus doesn't work - but Fpc does! -. Try it yourself using cmem as a template, simply rip out the silly size management.
Could any of you 2 indicate where in lazarus memsize is wrongly used, please, and how those limited number of places do affect Lazarus. Also how would ansistring work in FPC without MemSize ?
[I don't know what is failing, I have not tried. It could even be that it's not MemSize that is the problem, but that some code tries to simply access the hidden size field. Either Thaddy has more info or you could play around with it yourself.The info that I have is that a memory manager implementation for Delphi doesn't need to store length info.
The info that I have is that a memory manager implementation for Delphi doesn't need to store length info.Without knowing the Memsize of an assigned pointer, the ansistring, unicodestring and widestring would just NOT work in FPC, try recompiling FPC, any recent version without use of MemSize, you wont go very far.
When I subsequently rip out the length information from cmem in Freepascal that manager seems to work in Freepascal, but not in Lazarus.
So at least for those platforms there is technically no need to store the size, although they store the size of the allocated block and not the actual used length.That is exactly what happens (and is exploited by FPC) in heap.inc. FPC system unit is not clean because it assumes that memory blocks are allocated rounded up to 16 bytes (see note in astrings.inc.NewAnsiString that goes like { request a multiple of 16 because the heap manager alloctes anyways chunks of 16 bytes } ). The comment itself is a lie because newansistring does not round up its request to upper 16 bytes bound, this is something I changed in my 3.0.6.
Once I can drop the size, the memory manager can also have better alignment.Except for special case, aligning on SizeOf(PtrUInt) is quite sufficient.
Fails with Lazarus....works with Freepascal.Works without a glitch on my W10 system (heap.inc or cmem and with/without my heaptrc new stuff).
I don't know what is failing, I have not tried. It could even be that it's not MemSize that is the problem, but that some code tries to simply access the hidden size field. Either Thaddy has more info or you could play around with it yourself.I unsderstand well what you suggest, (And imagine very well doing a hack myself :-) ) but that would be like searching for a needle in a haystack.
[I don't know what is failing, I have not tried. It could even be that it's not MemSize that is the problem, but that some code tries to simply access the hidden size field. Either Thaddy has more info or you could play around with it yourself.The info that I have is that a memory manager implementation for Delphi doesn't need to store length info.
When I subsequently rip out the length information from cmem in Freepascal that manager seems to work in Freepascal, but not in Lazarus.
Once I can drop the size, the memory manager can also have better alignment.
It is really true that modern C allocators are faster than the default Freepascal manager. and threadsafe without locking, even scale better: they use a.o. lockfree patterns.
In the past this was not the case. Now it is the case for almost any application, not only threaded ones.
[Without knowing the Memsize of an assigned pointer, the ansistring, unicodestring and widestring would just NOT work in FPC, try recompiling FPC, any recent version without use of MemSize, you wont go very far.As you can see from my code, I implemented it.
That is exactly what happens (and is exploited by FPC) in heap.inc. FPC system unit is not clean because it assumes that memory blocks are allocated rounded up to 16 bytes (see note in astrings.inc.NewAnsiString that goes like { request a multiple of 16 because the heap manager alloctes anyways chunks of 16 bytes } ). The comment itself is a lie because newansistring does not round up its request to upper 16 bytes bound, this is something I changed in my 3.0.6.Yes. Indeed if I follow you correctly.
Heap.inc makes quite a few abusive assumptions about growing blocks. As an example when TFPList and siblings expand it may very well be that allocating additional memory isn't requested because Heap.inc has already decided to give much more memory, and it gets worse and worse as list grows.Not the case on modern processors, depending on optimizations (sse, mmx,avx etc on x86 and vppX on arm.QuoteQuoteOnce I can drop the size, the memory manager can also have better alignment.Except for special case, aligning on SizeOf(PtrUInt) is quite sufficient.
Where to start.
1° cmem on windows. As Grumpy writes _msize can be used to retrieve the size of the allocated memory instead of having a header sizeuint containing the size.
Note that heap.inc has a similar approach in its own structures.
cmem using _msize. Tested with rebuilding FPC 3.0.4 latest (3.0.6 in my private branch) and rebuilding a relatively recent lazarus.
MemSize MUST IMPERATIVELY BE IMPLEMENTED CORRECTLY in any memory manager otherwise the
following FPC routines would never work. They are
- fpc_AnsiStr_SetLength
- fpc_UnicodeStr_SetLength
- fpc_WideStr_SetLength
The least one can say is these are pretty commonly used ...
I mention them because I did a few changes (3.0.6) in these places to put all memory manager (that is heap.inc and cmem) on equal footing regarding string pre-overallocation.
[And there you hit a problem that these are often used functions which a procvar would slow down. Which is probably why it is as it is now. (just doesn't show up in the simplistic benchmarks)It also shows up in quite complex benchmarks. cmem's as they are now are much more advanced than a simple heap manager as it was before ~2008-2010. I fell into this trap of ceteris paribus. cmem's are not being equal.
This would make the cmem interface variable. If for some reason you need a specific windows version of CMEM, just use make a windows specific unit of cmem. (WCmem)Not variable, only fully complying with TMemoryManager requirements as defined in the WIKI.
And there you hit a problem that these are often used functions which a procvar would slow down. Which is probably why it is as it is now. (just doesn't show up in the simplistic benchmarks)There I really don't understand what is the problem with procvar, can you explain please.
Actually I found at least 2 lines that could cause troubles they areGood find. :o That should indeed be fixed. Preferably before we release 3.2 which contains that as well...
bk edit : bullshit -> ignore pleaseActually I found at least 2 lines that could cause troubles they areGood find. :o That should indeed be fixed. Preferably before we release 3.2 which contains that as well...
I just checked the original code. They're a false alarm: they rely on the internal structure of dynamic arrays, not on the size of the allocated memory. So nothing to see here...Attached 2 possible (untested) patches.Actually I found at least 2 lines that could cause troubles they areGood find. :o That should indeed be fixed. Preferably before we release 3.2 which contains that as well...
1° for lazarus trunk
2° for FPC trunk
I just checked the original code. They're a false alarm: they rely on the internal structure of dynamic arrays, not on the size of the allocated memory. So nothing to see here...I rushed a bit to fast on these because they looked so much like hacking getting the size of a memory block. One gets confused pretty easily with indirected indirect pointers.
One gets confused pretty easily with indirected indirect pointers.I hear you :-[
So? it looks like it is possible to rip out the size?Did you test BrunoK's adjusted cmem without the size with Lazarus? Cause maybe it's a package you have installed in Lazarus which is misbehaving there.
Just hanging around memory allocation, at least on windows, I have run some tests about memory block aligments supplied by heap.inc / cmem / winheap (see rtl\win\winheap.pp unit attached).So? it looks like it is possible to rip out the size?Did you test BrunoK's adjusted cmem without the size with Lazarus? Cause maybe it's a package you have installed in Lazarus which is misbehaving there.