Your reviewer found an unpopular posting by synopse (you can read it and jump back to this site) and read about how slow Delphi applications are.
Your reviewer brought an Intel Core i7 - 980, 16gigs RAM, Intel SSD HDD and x64 Windows 2008 as personal workstation because your reviewer could not tolerate slow Visual C++ compiles, somewhat slow speeds for C# compiles...
Pride comes before the fall...
Everyone in the whole world thinks C#.NET applications smells stinky and since it's written in NET - these applications are slow and consume valuable memory...
Here comes applications built with Delphi showing-off the supposedly fast memory manager (FastMM), new, improved speeds and supposedly faster maths...
The reality is:
- Delphi multi-threaded applications utilize just one core. if you have a Delphi app, all cores just freeze and your Delphi app runs like as it was sitting on a single core. Even if you have 2 or 3 cores... or 4 or 6 or maybe 16 cores... your Delphi app runs like as it was sitting on a single core.
- The maths is based on i486 with some FastCode MMX assembly in the RTL.
- There are serious threading issues
Delphi for scalable apps? Don't bet your career on it...
Delphi apps that could possibly scale and provide better performance and speed are "not there yet" while Visual C++, Java and NET applications are "there". Since Delphi apps cannot "perform" and "scale", the race is over before it has started.
To fix these issues, you need to fix issues with the Delphi Compiler and provide better multi-threading support...Of course, only Embarcadero can do this...
But wait -
Embarcadero is probably preparing for Delphi 2011 launch (ref: www.delphi.org - "It isn’t a hard and fast rule, but generally speaking CodeRage is pretty close to the release of the new version of Delphi, not that anyone will be surprised by that time frame.")
Let's hope these multithreading issues are fixed in Delphi 2011... or maybe in Delphi 2012 or ... Delphi 2015 or ...
Your reviewer brought an Intel Core i7 - 980, 16gigs RAM, Intel SSD HDD and x64 Windows 2008 as personal workstation because your reviewer could not tolerate slow Visual C++ compiles, somewhat slow speeds for C# compiles...
Pride comes before the fall...
Everyone in the whole world thinks C#.NET applications smells stinky and since it's written in NET - these applications are slow and consume valuable memory...
Here comes applications built with Delphi showing-off the supposedly fast memory manager (FastMM), new, improved speeds and supposedly faster maths...
The reality is:
- Delphi multi-threaded applications utilize just one core. if you have a Delphi app, all cores just freeze and your Delphi app runs like as it was sitting on a single core. Even if you have 2 or 3 cores... or 4 or 6 or maybe 16 cores... your Delphi app runs like as it was sitting on a single core.
- The maths is based on i486 with some FastCode MMX assembly in the RTL.
- There are serious threading issues
Quoted:
- Default memory manager, i.e. FastMM4, uses a LOCKed asm instruction for every memory allocation or dis-allocation.
- string types and dynamic arrays just use the same LOCKed asm instruction everywhere, i.e. for every access which may lead into a write to the string.
Delphi for scalable apps? Don't bet your career on it...
Delphi apps that could possibly scale and provide better performance and speed are "not there yet" while Visual C++, Java and NET applications are "there". Since Delphi apps cannot "perform" and "scale", the race is over before it has started.
To fix these issues, you need to fix issues with the Delphi Compiler and provide better multi-threading support...Of course, only Embarcadero can do this...
But wait -
Embarcadero is probably preparing for Delphi 2011 launch (ref: www.delphi.org - "It isn’t a hard and fast rule, but generally speaking CodeRage is pretty close to the release of the new version of Delphi, not that anyone will be surprised by that time frame.")
Let's hope these multithreading issues are fixed in Delphi 2011... or maybe in Delphi 2012 or ... Delphi 2015 or ...
5 comments:
That's why modern db engines for Delphi use their own memory managers which are scaling much better for their usage patterns(DBIsam & NexusDB at least).
For clarify (in synopse article mentioned):
LOCKed instruction are used ONLY when IsMultiThread variable is set or FastMM4 is compiled with AssumeMultiThreaded - see sources.
So if you use threads (this set IsMultiThread) locked instuctions are used
In FastMM4 is option to use spins instead of lock and it solve problems with locks. On 8 core processor I can get 100% use of processor and 6-7 times speed up from 1-2 times before.
But there is possibility to make it even more quicker. If FastMM4 use more pools (for different threads or randomly used pools) it can be even a little faster because in my case only waits/spins are in FastMM4.
In case of multicurrency Delphi lack keywords for futures, parallel tasks and there is problem with exception in threads. There are libraries likes OmniThread or AsyncCalls but is not the same like build in keywords.
Mike, there are locks and then there are locks. Reader/Writer, Mutex, Semaphore, Spinlocks etc. All have certain advantages, disadvantages which include contentions, deadlocks, race conditions.
Our memory manager uses CAS ("compare and swap" using lock cmpxchg - http://en.wikipedia.org/wiki/Compare-and-swap). While technically still a lock this is a lock at physical level, which is as close to "lock-free" as you can get.
Yep, FastMM is not good for heavy multi threading, that's why I made a fully scaling memory manager: ScaleMM http://code.google.com/p/scalemm/
This one scales perfectly (TopMM does this too but is bit slower).
By the way: .Net scales better than FastMM but does not scale perfectly! I have done some test some time ago, and even .Net 4 does not scale good (on a quad core, not more than 70% CPU, and performance of about 50%)
Post a Comment