You are not logged in.
We just released a new unit to the source code repository.
It's a simple, small and compact MM, built on top of the main Memory Manager(FastMM4 is a good candidate, standard since Delphi 2007), architectured in order to scale on multi core CPU's (which is what FastMM4 is lacking).
Original code is ScaleMM - Fast scaling memory manager for Delphi by André Mussche.
Modifications/fork to SynScaleMM:
- Based on http://code.google.com/p/scalemm r8 revision, from Nov 19, 2010;
- Compiles from Delphi 6 up to Delphi XE;
- Some pascal code converted to faster asm;
- Some code refactoring, a lot of comments added;
- Added (experimental) medium block handling from 2048 bytes up to 16384;
- Released under MPL 1.1/GPL 2.0/LGPL 2.1 tri-license.
Offline
Refreshed version of SynScaleMM.
Now could be used on production.
Scales very well on multi-core CPUs, with thread-intensive real applications (like servers).
See this picture (taken from ScaleMM site in google code):
In this graph, horizontal scale is the number of threads, and vertical scale is the execution time (the lower, the better).
Offline
In another benchmark:
Graph groups are the following:
1. Borland's MM (only for Delphi 7);
2. FastMM4;
3. SynScaleMM over Borland's MM (only for Delphi 7);
4. SynScaleMM over FastMM4.
The higher, the better.
See http://synopse.info/forum/viewtopic.php?pid=892#p892 for explanations.
Offline
To download this unit, just go to our source code repository:
http://synopse.info/fossil/finfo?name=SynScaleMM.pas
Log in as anonymous, then select the wanted version (the upper the later in the list), then click on the "Download" link topmost of the page.
Offline
Need memory leaks report function.
Offline
Need memory leaks report function.
That's a good observation.
If you need memory leak reporting and debugging, use FastMM4 in FullDebugMode, with the external library.
Then, when your application has no memory leak, just include the SynScaleMM in your .dpr uses clause, and check about speed enhancements in multi-thread.
Even FastMM4 has in fact two part of code: one optimized for production (written mostly in asm), one slower but more complete for debugging and memory leak reporting.
I don't want to reinvent the wheel, so FastMM4 memory leak reporting sounds perfect to me, and there is no plan to add such a feature to SynScaleMM in the future.
Offline
I've uploaded a new version of SynScaleMM.
See http://synopse.info/fossil/finfo?name=SynScaleMM.pas
It's now synchronized with r19 revision, from Dec 6, 2010, with some enhancements proper to SynScaleMM. In particular, I tried to clean 5 points of implementation against this r19 revision of ScaleMM.
For example, there is a new SPINWAITBACKOFF conditional, which is defined by default, in order to follow the Backing Off Locks with Spin-Wait Loops, as stated by Intel documentation.
Now seems working with C_ARRAYSIZE = 32... I've cleaned some Scale_Getmem() and Scale_Freemem() calls.
Offline
Hi,
I made simple benchmark test programm specialliy for FastMM4 & TBBMM using 4 threads (Delphi 2007 on dual core)...
Just using some special benches the benchmark application crashes using lastest SyncScaleMM O:(
How to drop/send this simple test bench to get ride of GPF's...
Hp
Offline
1) are you sure you put SynScaleMM as the first unit in your .dpr file?
2) you can send to me some source code by email when clicking on the "Email" button below my name, left side of every post of mine
Offline
Hi,
yes it's the only one...no FastMM4 used!
will send it...
Hp
Offline
I've created a calculation intensive application in Delphi. Previously it was running ok at a Quad core PC at about 60-70% of the max. cpu capacity.
Yesterday I've assembled a heavily overclocked I7-990x system. I was anxious to get my software running, only to find out that the performance dropped to about 16% on all 12 cores ater a minute or so......
After a bit of googling I found your memory manager, installed it and was able to get the maximum performance (100%) out of all cores, a speed improvement of 625% !!
That really made my day
One thing I noticed though: often when a calculation finished an access violation was triggered.
Initially I thought the overclocking made my system unstable, but it also ocurred on other systems.
Once I enabled the {$define PURE_PASCAL} compiler switch the program seems to be running stable again. Maybe there's a glitch in the assembly code?
I'll continue testing today and let you now how it works out.
Thanks again!
Offline
Update:
I've tested my system all day yesterday, and everything still seems stable.
Offline
Same result as before, the calculation becomes unstable (Access violation) in 3 of the 5 runs that I did.
While using pure pascal i did another 6 runs which all went fine
Last edited by marven (2011-04-06 13:07:24)
Offline
Hello,
Is there some performances degradation to define "PURE_PASCAL" ??
If yes.. is this noticable ?
(I mean in a real life application)
Thank you
Carl
Offline
PURE_PASCAL is slower than the asm version.
But if you need multi-thread scaling, it could be a safe solution.
For performance, it will depend on the application.
So use your application, take a clock, and guess what's the better for your purpose.
Offline
I've just installed the new version of Delphi (XE2) and SynscaleMM no longer seems to work.
The error reported by delphi is "SynScaleMM.pas(1736): E2010 Incompatible types: 'NativeInt' and 'Integer'"
Apparently the compiler expects a NativeInt instead of an Integer for variable aSize in "function Scale_GetMem(aSize: Integer): Pointer;"
Is this something you can easily fix?
Offline
Do you plan to fix instability issues with the latest SVN version?
Using MemoryManagerBV201 two test are failing: TManyThreadsTest and TStringThreadTest.
Offline
We do not use it in production, so we are not very inclined to spend time in this unit yet...
SynScaleMM is a Proff Of Concept, IMHO.
But we never did find any issue in our own code yet.
Perhaps the SAPMM unit is a better alternative.
See https://code.google.com/p/sapmm/
Offline
For those who need a paper written perfectly. http://bigessaywriter.com/blog/the-secr … ect-memory This blog is truly awesome. There are articles, provided by excellent writers.
Offline
hi, i today loaed some old code and remember i used synscalemm years ago.
Is this still any advantage? I am using Delphi Berlin 10.1 right now. I think not use today?
Offline
Starting with Delphi Tokyo 10.2.2, there is an instability with this. Seems that a change in the RTL might be the cause. With significant thread creation, there are access violations on TMonitor.Destroy and also in GetMonitor... I am wondering if anyone else is experiencing this and what might be done to resolve it. It is not very simple to experiment with changes in system.pas. :-( Didn't have any trouble in Tokyo 10.2.1.
Offline
Turns out this is a bug in System.pas. I worked out the fix, but it requires rebuilding system.pas.
You might vote for the report here so they will hopefully release a hotfix. Pretty major bug for anyone using a different memory manager from GETMEM.INC.
Offline
Weird bug, which shows that they don't have any regression test with external memory manager.
Or... don't use TMonitor, but explicit critical sections, for locking resources.
We never use TMonitor, since it was a bloated feature, to our understanding - and is not compatible with FPC or older versions of Delphi.
Offline
TMonitor is being used many places in rtl now. I just did a search for TMonitor.Enter under source\rtl\sys -- there's a lot! If you use a third party memory manager and do any multi-thread code in 10.2.2, you can only avoid the bug if TMonitor.Enter is never called on a locked object...
Offline
Thanks. That was one approach I considered. But it looks like the changes were intended to avoid conditions where these pointers are freed after the memory manager is unregistered from system.pas, so rather than patch it at runtime to force it to go through my MM, I just recompiled system.pas to fix the bug...
Last edited by obl918 (2018-01-17 16:56:11)
Offline