To all the "Delphi codegen is horrible" folks out there - has any of you ever tried Delphi2Cpp? I was wondering if a translation to C++ code and then feeding that to the compiler of your choice will lead to a better result. Also how compatible is Delphi2Cpp with Delphi code containing generics and that stuff?
From the front page of the Delphi2Cpp site (http://www.texttransformer.com/Delphi2Cpp_en.html):
ReplyDeleteDelphi2Cpp is based on a complete parser for Delphi 7 and yields optimal translation results by use of the type information of the VCL and other included units.
So, doesn't seem likely that generics code will be translated into template based code.
Very hard to imagine that this could be viable with a language as rich as Delphi. I have experience of f2c for converting Fortran 77 numerical code to C. The resulting C code is unreadable and unmaintainable. Yes it works, but the two languages are so simple that this is viable. Modern OOP code with generics, anonymous methods and so on doesn't seem very amenable to such transformation.
It is really rare that I have codegen performance issues - but I can definitively relate to those that are affected.
ReplyDeletewhat about FreePascal codegen ?
ReplyDeleteBTW I'm more horrified by some part of the source code than the codegen ;)
Will the desktop compiler also use LLVM in next releases ?
Lars Fosdal You just don't know that you have these issues because you probably are not affected by them that badly that it matters (or that anyone raised the flag) but they are there in even the simplest code (aka stack juggling)
ReplyDeleteStefan Glienke Precisely. Our software spend far more time waiting for the db, than churning code fast. That said - I would most def like to see the code gen improved, but also important - improvements to multithreading scalability in the MM and RTL.
ReplyDeleteJavier Hernández and Paul TOTH: At least there already is a const cWinNX32Platform in PlatformApi.pas.
ReplyDeleteI've never seen nor I believe that an automated translator would work for a *real world* software.
ReplyDeleteEdwin Yip Depends on how good the translator is - watch https://www.youtube.com/watch?v=C-_dw9iEzhA
ReplyDeleteWhile it certainly would be somewhat better, you won't be able to capitalize on the huge wins that stack-allocated objects and proper templates brings to the table.
ReplyDeleteAsbjørn Heid That is true, just converting code only does half the job (if at all)
ReplyDeleteJavier Hernández it uses 3.3 on Windows in Seattle, but managed to make performance even worse than 3.1. Really hope they get together in next update. Shame they stopped short of 3.4. That would have given full C++14 support instead of "just" C++11.
ReplyDeleteBy using a better compiler you can get maybe 2x performance gain, by using a better algorithm you can get 100x performance gain.
ReplyDeleteThose who are complaining about the code generation, did you make your part of the job? Do you use the best approach possible? Do you deploy to win64 instead of win32? Is your code parallelized? Have you ever profiled your code? Have you already inlined/unwinded performance critical functions? Do you manage memory efficiently?
Those who are complaining about poor RTL implementation are also funny. Just don't use RTL, implement the data structures you rely on yourself.
Javier Hernández ever noticed that magic codeblock?
ReplyDeleteASM
END;
Magic things happen there, like SSE!
(Up to SSE3 IIRC to be more precise, in Delphi XE)
Javier Hernández Well, ASM works in Delphi, but C++ does not.
ReplyDeleteIt's pretty poor that the 32 bit compiler cannot emit SSE opcodes for floating point arithmetic
ReplyDeleteHas anyone ever written a binary optimiser, ie process the machine code and optimise it? Could work for any native application... I'd write one but I haven't used assembler in anger for 30 years! I guess it could be based on pattern recognition, ie recognise the stack juggling that Stefan mentioned... optiomise it, rewrite the binary (not as simple as it sounds if offests need to change etc). Not saying it would be a simple task, but it does bypass the compiler... we've been waiting so long for a better compiler (and better language features) that I'm not going to hold my breath.
ReplyDeleteThe desktop compiler is a second class citizen these days, unless it has something to do with mobile or beacons or (insert latest buzzwords here) then embarcadero are not interested.
Vincent Parrett I think Johan Bontes mentioned that he was working on something like that some while ago.
ReplyDeleteStefan Glienke
ReplyDeleteYes, working on it. I'm using the UnivDisasm as a base to grok the assembly and then do a pattern match on stack juggling, eliminate obvious unneeded code and than do a liveliness analysis. Not at the stage where I'm willing to show it to the world though.
David Heffernan "Modern OOP code with generics, anonymous methods and so on doesn't seem very amenable to such transformation" Nim cross-compiles to C and it has generics and OOP. Vala implements OOP and also cross-compiles to C. I don't think it would be impossible to translate Delphi to C++. As you know, Cython and Nuitka can even translate a lot of Python to C and C++.
ReplyDeleteEdwin Yip Code translation does work in the real world. OpenSUSE translated their Yast configuration software from their own homegrown language, YCP, to Ruby by writing an automatic translation program:
ReplyDeletehttps://news.opensuse.org/2013/10/10/coming-soon-opensuse-13-1-with-yast-in-ruby/
Vitali Burkov " by using a better algorithm you can get 100x performance gain". Very true. And let's not forget - most of the time your application is "fast enough" and doesn't need any performance gain. ;-) It can also be cheaper/quicker to throw faster hardware at problems than spend lots of expensive developer time performing micro-optimizations.
ReplyDelete"Those who are complaining about poor RTL implementation are also funny. Just don't use RTL, implement the data structures you rely on yourself."
That's not a good idea; you've paid $1000+ to be able to develop faster. If you can't use the RTL you'll have spent that money for nothing and spend a great deal of time re-implementing what you already paid for. If the RTL performance is really unacceptable you need to use a different tool for the project or wrap optimized libraries (less time-consuming than writing your own).
Alexander Benikowski If you paid $1000+ and have to sit there hand-writing your own ASM because the compiler won't use modern instructions, I don't know what to say. The productivity loss of doing that is mind-boggling.
ReplyDeleteUwe Raabe So if performance was critical you'd pay $1000 for Delphi and hand-write your code in assembly instead? That's a "if the only tool you have is a hammer..." kind of thinking. C++ doesn't work in Delphi, but it works in gcc or clang (for free) or Visual Studio. Wrapping a C++ library in that instance would be a lot more sane than hand-writing assembler.
ReplyDeleteThanks for the info. While auto code translation might work in some specific real world cases, it's not a common option in most cases, as far as I know.
ReplyDelete