See how you can use Delphi's upcoming new language feature to improve performance of your code.
See how you can use Delphi's upcoming new language feature to improve performance of your code.
https://blog.grijjy.com/2018/11/02/inline-variables-can-increase-performance/
https://blog.grijjy.com/2018/11/02/inline-variables-can-increase-performance/
Erik van Bilsen "The code that Delphi actually generates is different for the pseudo-code presented here. It is not as efficient as it should be, but hopefully this will improve in the future."
ReplyDeleteErik van Bilsen I consider this a bug, the code generated by the compiler should be able to follow the steps presented in your article!
ReplyDeletePlease report this in the quality portal, Delphi 10.3 can not be released with this broken inline variable feature!
Let's stay 5 months until the embarcadero release a patch for the compiler!
I'm sad to know that the compiler code is not able to handle this!
Attila Kovacs Yes, Delphi puts the finalization code into hidden try..finally blocks. I could have shown that in the "pseudo code" examples, but omitted it to keep the code clear. In fact, one of the reasons inline variables aren't as efficient as they should be is that Delphi generates a hidden try..finally block for each managed inline variable.
ReplyDeleteWesley Bobato I already reported this issue. I don't think that inline variables are broken though. They just could be better ;)
ReplyDeleteErik van Bilsen I agree that this is not "broken", but the least we Delphi users expect from the compiler is what you cited in your article!
ReplyDeleteThanks for reporting the Delphi community thanks :)
Wesley Bobato given the potential performance improvements the compiler already could do, and how long they could have been done, I would not bet on these new improvements becoming reality anytime soon.
ReplyDeleteJeroen Wiert Pluimers I feel like I'm sinking in a stuck ship and maybe I should jump off before it sinks.
ReplyDeleteYou all are more active in the Delphi community than I am!
So I ask what's missing for the compiler to take the next step?
Based on the article by Erik van Bilsen, the 10.3 compiler will not launch as well as it should with inline variables.
I always think about productivity will be that I will have to make manual optimization adjustments until I die!
I love Delphi, but I feel like other compilers are swallowing ours.
I'll wait for the 10.3 release and compare the generated code.
I hope to return here happy to say that I was wrong.
Attila Kovacs What is 99% of the cases? there are infinite possibilities of projects
ReplyDeleteLet's wait for the release and compare is how I can measure performance.
I'm afraid that all my +100 projects will be in the 1% where the compiler is not optimized.
Don't let the door hit you on the way out
ReplyDeleteWesley Bobato see for instance blog.synopse.info - Which Delphi compiler produces faster code? - Synopse and https://helloacm.com/floating-point-optimization-comparison-in-delphi-2007-and-xe3/ and https://plus.google.com/103246155735524926641/posts/MKTLEZoyE5R and https://stackoverflow.com/questions/6372017/does-delphi-xe-produce-faster-code-than-delphi-2007
ReplyDelete"...For floating-point arithmetic, the Delphi compiler is nowadays deprecated. For instance, the current Delphi compiler is outperformed by latest Javascript engines using on the fly compilaton into SSE: you'll have to code SSE by hand for acceptable results. I hope that SSE code in the upcoming 64 bit compiler will change the results here. As far as appears in this comment, FPC 2.5.1 generated exe is already faster than Delphi (similar to TraceMonkey, at least), because it handles SSE. Nice for an Open Source compiler! :) "
ReplyDeleteJeroen Wiert Pluimers Thanks for sharing :)
ReplyDeleteInteresting is that I do not compile my projects in 64 bits, so I do not see the use of SSE, most of our 75% clients use 32 Bit yet.
Interesting is that FreePascal be better than Delphi in some scenarios!
What strikes me is that SSE exists almost 20 years because the embarcadero does not include in 32 bits?
Did you report this on the quality portal?
Ralf Stocker I've never used FreePascal but it uses SSE with 32 bits?
ReplyDeleteBecause the embarcadero is not following these steps, did you report it?
We can not stay back, the embarcadero should know that the "Brother" of Delphi Free! is passing in front of you as a code generation!
I sincerely would like this to be improved before launching 10.3
32-bit SSE is pretty gimped compared to 64-bit. I'd prefer that Embt focus on 64-bit.
ReplyDeleteLars Fosdal But the 32-bit platform is supported by Delphi :)
ReplyDeleteFollowing your words does this mean that the 32-bit Delphi support exists only to die tomorrow?
The world market is very fragmented today, making a prediction is complex, at school where my daughter studies they use Windows XP 32 Bits, she learned Windows, Microsoft Office and etc.
I do not believe that the school will buy 200 licenses, of Windows 10, without having need.
My wife has an iphone 4s for many years I already insisted that she change, but she does not fill a need.
How to deal with all these situations?
As with any technology, there is a price with staying behind on old tech, as well as for keeping up and staying modern. From a tech provider's perspective, there is no sense in investing in the old, as the old is already "good enough", while the new is where significant improvement pays off.
ReplyDeleteAs for schools, it is more likely that they move onto Chrome books and Google Docs or Office 365.
ReplyDeleteLars Fosdal If schools will follow these trends, does that mean that the "embedded" software we compile will become obsolete, does that mean we will have to only develop backends with Delphi? then we should migrate to "JavaScript" to consume our Delphi services?
ReplyDeleteI think that consumerism and capitalism are a model of society that the future can not resist, the benefits of switching hardware are often insignificant in practice.
So keeping the compiler up-to-date on "obsolete" platforms such as 32 bits is important for a sustainable world.
I don't disagree, but I think that Embt has a different focus.
ReplyDeleteLars Fosdal Here in Brazil you have an excellent course in compilers and the goal is to develop better software without having to change hardware.
ReplyDeletehttp://lac.dcc.ufmg.br/
homepages.dcc.ufmg.br - homepages.dcc.ufmg.br/~fernando/projects/CompilerResearchUFMG.pdf
perhaps the embarcadero see this link and reflect on the directions of its outbreaks.
Wesley Bobato they would need to bump up the minimum x86 processor requirement for that. From back in the days I was really close to the R&D team, I remember that won't happen.
ReplyDeleteNow, much later, I don't think they will ever do that for x86; x64 needs more modern processors so that might happen.
https://en.wikipedia.org/wiki/X86-64#Intel_64
Jeroen Wiert Pluimers x64 need more modern processors?
ReplyDeleteThis list of Intel x64 processors is incomplete and outdated :)
The amount of x86-64 processors is more than enough for the world's population and we have several manufacturers in the market.
Honestly I like Delphi I think you guys working on compiler development could dedicate a fraction of your time to optimizations not just bug fixes!
How many people work on compilers? here in Brazil we work a third of the day is usually what determines the labor laws.
If 10 people work on it, it equals 80 hours of work a day.
80 x 365 = 29,200.
But let's think I'm overreacting because I do not know the rules and laws of the United States, even if it's 20,000 hours is more than enough to deliver a positive result.
Whoever works with compiler knows the backstage of processors and so on.
I do not see that this is a problem for the compiler development team.
Anyway I will continue to use Delphi because all our projects contain hundreds of VCL components and third party the cost of migrating is greater than doing manual optimization.
I hope that here is a democratic and liberal place to discuss and make a better world :)
A great day for all of you.
Wesley Bobato on x86, Delphi includes the FDIV fixes, as minimum requirements are Pentium; x64 requires AMD K8, Via Nano or Intel Prescott E0 (desktop) or Prescott 2M (Xeon).
ReplyDeleteFor intel that's 1993 (x86) versus 2005 (x64): a huge difference.