Originally shared by A. Bouchez
Originally shared by A. Bouchez
http://blog.synopse.info/post/2014/06/09/Performance-comparison-from-Delphi-6%2C-7%2C-2007%2C-XE4-and-XE6
http://blog.synopse.info/post/2014/06/09/Performance-comparison-from-Delphi-6%2C-7%2C-2007%2C-XE4-and-XE6
Interesting observations, Arnaud. To be fair, we have been stuck on unimproved CPU speeds, too. Parallelism would seem to be the only path for performance increases, other than through better compiler design and better optimizations. Your summary suggests that there has been little happening on those fronts, and now XE7 sticks its toes in the water on parallel loops.
ReplyDeleteAt a larger view, I think that either people are not taking the view that performance is sufficient (never true) or perhaps that there have been too many distractions from the pursuit of performance.
Each new version of Windows offers greater consumption of resources to paint the screen, but not so much in other areas. My Ivy Bridge i7 is nice, but in general, apps open in Win7 with about the same performance as Win2K apps did in Win2K. They are larger--much--and have more features, but increased performance is not usually one of them. For contrast, WinXP in a VM on the same machine is very fast. If I could bother mysaelf to install NT4 in a VM, it might be stunningly fast.
Oddly, I think there is stagnation in tools development. Not with respect to features, but with respect to fundamentals. We get more embellishments, more chrome, but we have seen long-standing defects continue to exist, and the list of defects grow longer as the new features inevitably bring new defects.
In XE6 and XE7, has ErrorInsight been repaired? Has J# been removed from the environment, or is it retained? I have seen comments regarding IDE stability improvements, and those are one of my top concerns, languishing here in D2007. But in my last big project, in DXE, I found it necessary to shut down features, as a trade-off against stability.
Bill Meyer
ReplyDeleteThere were some great pieces of codes like OmniThreadLibray (which you know well, if I remember well) ;) Will there be enhancements at language level, like a "yield" new keyword? Or would some OTL-like be bound to the RTL?
What worried me about the multi-thread efficiency of future Delphi, is that its low-level RTL was never freed from its locks (e.g. at FastMM4 level - they should offer an alternative for multi-core process), and, on the contrary, some awful implementation patterns were introduced. For instance, the [weak] attribute uses a TMonitor giant lock, so if you use it - which is mandatory with ARC and circular references - your multi core perfs won't scale.
Delphi apps are still very fast to run, using low resources, when compared to C#, Java or JavaScript, for instance. IMHO this is one huge benefit of our beloved platform. Manual memory management was never a problem to me, especially for performance sensitive applications.
The #1 rule for performance optimization is not the compiler, the language, neither the RTL. The biggest speed improvement comes from profiling, then changes of algorithms. A lot of developers see the compiler as some kind of "wizard" who would magically speed up thinks. They focus on code. Whereas, to quote Linus Torvald: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Adding a lookup table, cache some data, change the algorithm, tune your data structures, knowing how much heap allocation costs, using arrays to favor L1 CPU cache, even use the Alt-F7 asm-level step-by-step debugging in the IDE.... all this will give you performance for real-world applications. Then if it is not enough (e.g. for picture or video process, or for a server with a lot of concurrent clients), you may start to think about parallelism.
Like you, I always shut down Error Insight and similar buggy features in the Delphi IDE. Otherwise, you just can't work with it... Even the RTL libraries are not properly handled by the Error Insight compiler :(
The slow startup time (mostly due to the license check code AFAIK) of the IDE is also a concern to me, since I have to restart it quite often . When I compare with SmartMobileStudio (which opens and compiles a project as quick as Notepad starts) which is my 2nd IDE those days, and see how its IDE and compiler is improving every day, I feel a bit sorry for EMB.
For instance, there is only one compiler in SMS (whereas EMB fails to maintain all the diverse compilers embedded within Delphi): you can be sure that when the IDE offers you code completion, or show you errors, it will match reality. Just another world....