The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,728 other followers

Delphi and LLVM: what is your take on this?

Posted by jpluimers on 2013/12/27

One more for the weekend (:

I wrote about Some links on the Delphi compiler and the LLVM Compiler Infrastructure Project about a year and a half ago which caused a short discussion on the embarcadero forums. A few month later Robert Love showed his views in a response to Tim Anderson writing about Clang and LLVM in the C++ side of the toolchain. Tim Anderson wrote more about LLVM in the Delphi tool chain  in September 2012, then it went quiet for a while.

Since then the LLVM tool chain has integrated itself into both the C++ and Delphi toolchains and Wired wrote about LLVM.

Gunsmoker – who works at EurekaLog – wrote up some interesting comments in Russian (I hope the English Google translation is good enough).

In my view, the LLVM tool chain opens a lot more possibilities (shared back-end for Delphi and C++, coverage of more platforms, better optimization), but is also a lot slower and makes the debugging part a lot harder as the debugger is – symbol wise – much further away from the compiler than in the traditional setting (hence the 3 levels of debugging information that got introduced in Delphi XE5 and the compatibility problem that came with it).

I’m wondering what other users in the Delphi community think about the LVVM chain: is it working good enough for you? Should it be integrated further into the Windows/OSX parts of the chain?

–jeroen

26 Responses to “Delphi and LLVM: what is your take on this?”

  1. […] Delphi and LLVM: what is your take on this? « The Wiert Corner – irregular stream of stuff. […]

  2. Eric said

    I’m divided as well.

    On the one hand there is a promise for more platforms and better low-level performance, on the other hand compiler speed and debugger integration were among the last advantages of Delphi. And there is a clear risk (materialized in FMX) that RTL evolutions to suit cross-platform and the new compiler would reduce in massive slow-downs and increased instability

    The loss of lack of control over the compiler tool chain is also not a favorable point, as diverging interests issues will arise.

    All in all, I’m afraid that by losing their advantages (compiler speed, ability to debug release builds), gaining no differentiators vs competition and being always one step or two behind, this isn’t just going to be a re-run of the Delphi.net disaster.

    • Michael said

      Delphi is in a defined state now. We know what we can expect.

      Does Win32 still matter beyond what works already? The 64-bit compiler will remain for Windows. If there is a good reason to replace that piece of software or both, ok.

      But for Mac, Linux and Mobiles I can imagine that EMB could benefit. They still have all the freedom on those who platforms and mobiles anyway.

      I fear we will run into *look how cool and innovative we are, because we are on LLVM now* disaster. We don’t support the platforms in a clean fashion but rewrite the compiler several times with the same result. in case of EMB I would not waste too much time and money on building exceptional compilers.

      • Eric said

        Possibly, but my beef is that historically (at least since D5), most of the value of Delphi came from the compiler, IDE and debugger.
        In terms of libraries and framework, what came with Delphi was always behind the curve and/or not very stable, and third parties are what kept it in the race.

        This has been particularly (painfully?) obvious in the last releases, from FMX to DataSnap or LiveBindings, the record track is quite terrible. On both Android and iOS, the support for really native components is coming only from third parties…

      • Joseph Mitzen said

        @Eric:

        I’d partially agree with you except for the “always” part. In the beginning people chose Delphi because it really was a much more rapid/RAD development solution than C++ and the horror that was MFC. VCL was also more complete than what Visual Basic was offering. Only when .NET and Qt began to mature did Delphi begin to see serious challenges to the VCL (also around when the popularity began to plunge in the West).

        The other part that worries me is that I wouldn’t call the compiler or the IDE its strong points today. :-( The compiler is fast but pays for this with a lack of optimization and honestly gcc can run circles around it. The IDE like the compiler seems to be something complicated and brittle that they don’t want to touch so IDE problems like Code Insight that require deep structural fixes see no resolution release after release. I saw a link a few days ago to the first release of a Pascal plug-in for the award-winning IntellliJ compiler, which might be another one of those nails in the coffin.

        You’re right about the other support libraries also routinely coming up short in benchmarks and/or bug testing lately. I hate to use this term here, but this is what’s worrying me about a “death spiral”. Poor financial health leads to developer cutbacks which seem to be leading to the product falling apart around their ears. If that translates into decreased sales and more cutbacks a dangerous cycle may start. I’m also worried about this move to a six-month release cycle. While arguably necessary, even the yearly one seemed hard to keep up with them. Maybe moving to LLVM will help relieve some resources and pressure. Maybe some day they’ll just release an official plug-in for IntelliJ or ship a version in the box and only concentrate on FireMonkey – maybe even making *that* available with bindings for other languages? I don’t know. Having watched Nokia and Blackberry implode, I’m at least glad they seem to be doing *something* before it’s too late.

  3. woutervannifterick said

    Breaking changes like 0-based strings make it pretty much impossible to share the same codebase between the old and the new compiler.

    Just “recompiling” generates so many off-by-one errors that it requires a lot of risky tiny changes all over the code-base.
    Refactoring file I/O and network packets to deal with the lack of AnsiStrings and shortstrings feels like a waste of time. Maybe I would feel more confident to make a zillion changes if every line of code was fully covered by automated tests, but well.. reality is different.

    Besides that, rewriting old assembly code with pascal can be time-consuming. Same goes for dependencies to the WinAPI or third party libraries. I’ve tried (for fun, mostly), but eventually gave up trying to “port” old code to NEXTGEN.

    For new development it could be nice though, but I didn’t do extensive development with it yet.

    What I find cool is the combination of ARC and operator overloading on classes. That opens up the possibility to make some nice libraries. I’ve recently made a library with lots of vector and matrix calculations, and it’s really nice to have operator overloads with that. I had to make use of records for that, so I couldn’t use inheritance or polymorphism. There’s a lot of nesting and duplicate code because of that.

    In theory, I could already rewrite that in a much cleaner way for the NextGen compiler.
    But there’s not much use if I cannot run that code on Windows, because that’s still the main target platform.

    • jpluimers said

      I agree with the 0-based strings: I think it is a cardinal mistake, but is not caused by LVVM.

      When talking to Barry Kelly during one of the EKON conferences about 4 years ago, he envisioned a kind of ARC on Windows in order to support operator overloading on classes. He indicated it would be a long and difficult process for the compiler engineers. He really wanted it a lot, as it creates a ton of potential not limited to operator overloading.

      Hopefully ARC will come to Windows and Mac as well.

      After that, I’d wish a unified type system. But that’ll take an even longer while (:

      • Joseph Mitzen said

        JPluimers,

        I’ve recently begun writing some code in a language that does offer ARC, operator overloading of classes, and a unified type system, among other things. I agree that it is quite a pleasurable experience and quite powerful (also makes things that are hard/verbose in Delphi quite easy). I tried chastising Allen Bauer once over Delphi not having types as objects. :-) It seems like he was thinking about things like this. On the down side, in a reply on his blog post after he mentioned some of his own ideas in comment exchanges he then said that it needs to be understood that any change that is made has to be sold to management on the bottom-line revenue increase it will add to the product. :-( :-( This is an area where open source demolishes closed source and why open source dev tools are the norm today – the developers don’t need to design to marketing or accounting specifications. They can just ask “What would I love to have?” and then do it. :-) And given the open source nature, they probably are using the same tools they’re developing for other, paid, work so they’re “eating their own dog food” as the saying goes.

        I’ve found mentions from Bauer and David Intersimone of adding new parallel programming-related features as far back as 2006 and 2008 (and I believe the EMBT CEO touching on multicore during a CodeRage presentation in 2008 as well) but so far no sign of these features forthcoming yet. They would be another nice touch and something that might make the language stand out among others (so much of what’s on many of our wish lists are things that are already present in other languages).

        • jpluimers said

          Thanks for your insightful comments. As your name did ring a bell, I just went over some of your old contributions on forums and other media, and confirmed my memory: great contributions hitting the nail on the head virtually every time. https://www.google.com/search?q=Joseph+Mitzen+delphi

          I’d like to see the results in the parallel research into the product as well. In the mean time there is this great Omni Threading Library that works really well.

          If you like to contribute to libraries, please take a look at Spring4D and DSharp that recently moved to GIT repositories on BitBucket: https://bitbucket.org/sglienke/spring4d https://bitbucket.org/sglienke/dsharp There is very valuable material getting the most out of modern Delphi language features.

          A unified type system would be really great. Maybe ARC is a first step towards it.

  4. David M said

    It’s great – and was something I was hoping Embarcadero would do back when rumours of the next-gen and 64-bit compilers first appeared.

    LLVM is a powerful toolkit and they can achieve a lot more using it. I’m especially excited about the optimisation potential, as well as shared backends, debuggers and optimisations for both C++ and Delphi, but there are plenty of other good things about it. They’ve made the right decision.

  5. kmorwath said

    It’s just another nail in Delphi coffin. First, Embarcadero is becoming a VAR – get someone else tool, customize it, and try to sell it. Also it’s telling that as a development tool vendor, it’s unable to develop its own compilers – not a good promotion. Second, it means Delphi has to adapt its workings to the compiler (developed elsewhere, remember) and not vice versa. The lack of control over the compiler means Delphi must evolve adapting to LLVM, while before the compiler team would work with the Delphi team do address the language and framework needs, not vice versa. Sure, it does allow for covering more platforms, but what’s the price? The changes Delphi will undergo are huge and actually deliver a far less powerful language than it was before. Simpler, maybe – but do we really need a simpler language? There’s plenty of simpler – and less powerful than actual Delphi – cross platform languages, do we really need another one? What is Embarcadero really addressing? Its customer needs, or its internal needs, especially saving on skilled developers, and the investment needed in developing its own compilers? The more Delphi relies on external code and tools, the less I find reasons to keep on using Delphi, I can easily switch to other tools built on the same foundations, or switch to tools made by companies that still believe fully in their products and keep on investing in them without looking for cheaper shortcuts.

    • Konstantine Poukhov said

      Completely agree. Another nail in the coffin. Other then lots of troubles I do not see a single benefit fo customers

    • jpluimers said

      I disagree with your vision, as the LLVM framework is very flexible, so it allows lots of influence both in the front-end, middle and back-end.

      Christian Budde gave a great presentation about LLVM at ITDevCon that covered a lot of languages (including Pascal varieties like FreePascal, Smart Mobile Studio and Delphi). Go and see what he has to say: https://www.google.com/search?q=christian+budde+LLVM

      Given the number and variety of languages that use small or large pieces of the LLVM stack I don’t see that those languages start to coerce into one direction at all. To the contrary: there is a lot of divergence which is good.

      • kmorwath said

        Exactly. Lots of languages using LLVM. And where’s the Delphi advantage there, then? If FreePascal would use LLVM as well, why should I use Delphi? Because of FireMonkey? LOL!
        Meanwhile the core features are anyway in the hand of a group outside Embarcadero – which has different aims-, and we all know the relationship between Embarcadero and open source has never been good. Delphi is never cited in the LLVM home page among the projects using it, why? I believe Embarcadero will never be able to steer that project in any direction it may need. Also, like most open source projects, it is strongly Linux oriented, and its toolchain is also. Delphi has its stronghold still in Windows, and it’s destroying it to chase markets where it will have one digit market share at best. Nobody outside Delphi developers care about Delphi as a tool to develop iOS, Android or OSX applications. As nobody cared about it as a tool to write Linux applications, or .NET ones. Because it really had nothing edge and desirable to offer.
        I’m not saying LLVM is a bad project – I’m saying I do not believe LLVM is a good choice for Delphi users – IMHO it is only for a struggling company that can’t write compilers and it’s desperately trying to target other platforms.

        • jpluimers said

          Thanks for the extra explanation. I see your point, though I’m not fully agreeing with it. Delphi is attracting new customers not originally from the Windows world. The future will tell if that is good or not.

      • Joseph Mitzen said

        @KMorwath:

        You say LLVM is not a good choice for Delphi users. Do you feel the existing Delphi compiler, written in C and apparently undocumented code at that based on a post Barry Kelly once made to Stack Overflow, is more performant? The compiler has not seen attention in many releases. I just learned recently from the forum that an Int64 can’t be used in a for-loop in 64-bit Delphi! This is apparently due to some compiler optimization they apparently don’t want to try to fix/change. If the compiler is really that brittle, might it not be a good move for Delphi users, even if they’re doing it for budgetary reasons?

    • Michael said

      The story is pretty simple. It’s their freedom to do so. They will have to live with the result anyway. clang on Windows did not convince me 2 years ago.

      As long as the executable is as fast as a good hand optimized C program and when I press F9 I want a quick response. My toolchain is F9. Anything else is not important.

      As long as I get a Delphi Update that works or works better than before I will not even recognize and anything else I will simply not use. Why do I have the feeling that such a transition is about stalling for time. I don’t want to hear, this and that cannot be done because of LLVM.

      If EMB take the opportunity, create a new Delphi and try to get rid of old antiquated stuff no problem with that. It’s their product. Make a Delphi LLVM that rocks and people will take. And if an old Delphi does remain at the level of pure maintenance that’s an option. Maybe it’s better to separate the new stuff from the solid past.

      • William said

        Yes, F9 or more often the Project Build All is my too chain. I think EMB should be better in killing all the bugs reported in QC first!

    • Joseph Mitzen said

      >It’s just another nail in Delphi coffin.

      I don’t agree with this per se. I think perhaps a more apt description would be another sign of the problems that are putting nails in that coffin. More specifically, a sign that they lack the income and manpower to continue development at the pace they need to, which speaks against the belief by some that Delphi use and profits are rising. I think it’s a wise/necessary move but motivated by financial pressures, lack of resources and other internal problems that are bad signs.

      > First, Embarcadero is becoming a VAR – get someone else tool, customize it, and try to sell it.

      I’m not sure it’s at this stage either. But it would seem that the only distinguishing feature they continue to possess is their framework(s). Now if you want to make the case that even the new framework they had to purchase from outside (as well as the database system) because they lacked the time/means/talent/resources to develop it internally, that might be a good point. Despite Wayne Williams’ presentation at CodeRage 8 about the amount of resources that were/would be devoted to R&D, we’re not seeing a great deal of results from it.

      >Also it’s telling that as a development tool vendor, it’s unable to develop its own compilers – not a good promotion.

      Absolutely a fair point.

      >Second, it means Delphi has to adapt its workings to the compiler (developed elsewhere, remember) and not vice
      >versa. The lack of control over the compiler means Delphi must evolve adapting to LLVM, while before the compiler
      >team would work with the Delphi team do address the language and framework needs, not vice versa.

      This isn’t necessarily the case. LLVM is open source and thus EMBT is free to make changes and based on reading the license not publish the source for those changes either if they so choose. I’m not sure what changes EMBT/Delphi would need to the back end compiler that would be specific to it, if any.

      >Sure, it does allow for covering more platforms, but what’s the price?

      Not much. Slower compilation time with the gain of much more optimization possible (modern, multi-pass compiler technology). As is, LLVM is intended to be faster than gcc (but so far not faster per most benchmarks).

      > The changes Delphi will undergo are huge and actually deliver a far less powerful language than it was before.

      I don’t agree with either of those statements. What powerful features do you believe will be stripped from Delphi?

      > Simpler, maybe – but do we really need a simpler language?

      Yes. Very much so. In fact, I believe it needs more of a “spring cleaning” than they plan on giving it, and the VCL really needs a refresh. Check out the Dateutil library for an example of code that appears to pre-date object orientation!

      >There’s plenty of simpler – and less powerful than actual Delphi – cross platform languages,

      There are simpler – and more powerful than actual Delphi – cross-platform languages too. They employ the full gamut of modern advances in language design such as type inference. We have a lot further to go beyond the small changes Marco has been talking about to catch up to newer languages.

      >What is Embarcadero really addressing? Its customer needs, or its internal needs, especially saving on skilled
      >developers, and the investment needed in developing its own compilers?

      I’ll agree with you on the skilled developers, but perhaps the remaining users really need to accept the idea that Delphi sales aren’t what they used to be. Couple this with the fact that Embarcadero was a firm with financial troubles before it got taken private and it makes sense that they just don’t have the resources to do all they’d like. Honestly, it’s not a flashy, cool or exciting place or new start-up product, so it’s also going to have troubles attracting the best and brightest new developers even if they had the money to offer them a good salary.

      > The more Delphi relies on external code and tools, the less I find reasons to keep on using Delphi, I can easily switch
      >to other tools built on the same foundations, or switch to tools made by companies that still believe fully in their
      >products and keep on investing in them without looking for cheaper shortcuts.

      No argument there except for that fact that those external code and tools are generally a level of magnitude better than Delphi’s existing ones. :-( Compare FireDAC to DataSnap, the performance of gcc to Delphi’s compiler (in one toy benchmark talked about in the forums, the results were 1.6s for gcc and C vs. 6s for Delphi, with Delphi only catching up with hand optimizations that the gcc didn’t need. In fact at its highest optimization setting gcc would realize the benchmark function being looped didn’t change anything outside itself and completely eliminated it, something Delphi was not smart enough to figure out.).

  6. Peter said

    They should improve dead/unused code removal and also let us disable RTTI if not needed (which is true for 99.99% of all projects out there).

    • jpluimers said

      I really disagree with you. The whole concept of a visual form designer is backed by RTTI. Without RTTI it would be impossible. RTTI has the cornerstone since Delphi 1 and set it apart from Borland Pascal 7 and before.

      The RTTI capabilities added since the Delphi 2009/2010 timeframe allow for very powerful libraries like Spring4D, DSharp, MVVM, DUnitX, XML/JSON/SOAP/REST communication and much much more.

      • Peter said

        What if you don’t like these libtraries you’ve mentioned? The fact, that every code part can possibly be called in runtime, makes dead/unused code removal impossible. This way each and every bit of code will be linked into the executable… and it gets more and more every year.
        A compiler switch to disable such a thing would be great or a smarter way of implementing the needed features.

      • Joseph Mitzen said

        @Peter:

        If you don’t like those libraries then don’t use them, although I don’t see what’s not to like about them as they help bring some modern and much-needed productivity-enhancing features to Delphi.

        >…makes dead/unused code removal impossible. This way each and every bit of code will be linked into the
        >executable… and it gets more and more every year.

        This has been a fixation of some Delphi developers that I possibly understood in 1995 but can’t understand in 2013. Unless you’re distributing your code on floppy disks, I can’t fathom what difference a few kilobytes makes. I understand even less how optimizing for executable size takes precedence over the development productivity benefits of modern code features.

        The ability to turn off improvements to the language just doesn’t seem like something that useful or worthwhile an effort from Embarcadero for me. Why not try an executable compressor?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: