11 ms·

I'm not sure I love this. I mean, LLVM is awesome and everthing, but software monocultures are pretty bad. It's not like the situation is dire yet (given that t

• andi999 5y ago
  Yes, I think though gcc will go first.
  • nly 5y ago
    GCC will never completely die. MS though have been moving in the Clang/LLVM direction for years, so I would have zero surprise if VC++ was completely removed tomorrow. My feeling is, as soon as they can be sure they have achieved 100% binary compatibility, MS will jump. The optimizers in VC++ are light years behind, and companies like Apple are embarrassing them on the compatibility front with things like Rosetta 2 (which is a much harder problem to solve)
    • andi999 5y ago
      My understanding was the llvm was made because the code basis of gcc is too complicated. Since seems to be a killer move.
      • vlovich123 5y ago
        That was a long time ago and the actual primary reason was apparently Stallman missed an email [1], although I think the intentional technical hurdles to plugins was another of many reasons. When GNU moved all their software to GPLv3 and the business community decided they didn’t like that license and Apple brought LLVM as a serious contender. GCC hasn’t remained stagnant though. [1] https://lwn.net/Articles/632062/ https://lwn.net/Articles/632062/
        • andi999 5y ago
          Thanks for the article, I am not sure I fully understand it. Could you point to the section about the missed email? Also, do I understand it right, that emacs doesnt integrate well with llvm? (maybe that explains why in llvm presentations ppl use the 'other' editor, I always wondered why not use emacs)
          • vlovich123 5y ago
            > An interesting side note to the debate emerged when Liang Wang posted about LLVM creator Chris Lattner's offer to try to get LLVM's copyright assigned to the FSF back in 2005. It was part of an effort (that seemingly went nowhere) to integrate LLVM and GCC. Stallman never heard about the message: So basically, if Stallman hadn't have missed the message, there's a very real possibility that LLVM would have ended up licensed under GPLv2 & then re-licensed to GPLv3. The engineering world would probably look radically different if that had happened.
      • pjmlp 5y ago
        That was ions ago, and if not for anything else, Linux kernel will keep GCC around. Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.
        • riffraff 5y ago
          Why would the Linux kernel keep GCC around? I'm fairly confident the FSF would keep it alive for a long time, but I don't see why it would be necessarily be a priority for the Linux devs to keep GCC forever.
          • pjmlp 5y ago
            Linux kernel makes use of GCC C, not ISO C, also targets hardware that LLVM doesn't support. Android Linux kernel fork actually builds with clang, and Linux kernel is yet to accept the changes made by Google.
        • account42 5y ago
          There is significant investment in building Linux with Clang so I wouldn't count on Linux keeping GCC relevant forever. Doubly so with the inevitable rustc requirement.
          • pjmlp 5y ago
            The ongoing efforts to add a Rust frontend to GCC prove otherwise. No Rust in GCC? No play.
            • account42 5y ago
              Unlike C/C++, there is one canonical rustc where the language is developed and GCC will likely always play catch up.
              • pjmlp 5y ago
                It doesn't matter, if only GCC gets to play with Linux kernel. Rust is only following down the footsteps of D and Go.
    • malkia 5y ago
      There are probably lots of MSVC specific extension (COM, C++/CLR, some pragma file_hash-ing https://www.reddit.com/r/cpp/comments/ep77ey/cl_ph_or_pragma_file_hash/ https://www.reddit.com/r/cpp/comments/ep77ey/cl_ph_or_pragma... that would neeed to get ported) - just some examples that come to mind.
      • TillE 5y ago
        They could deprecate most of that stuff and let the old compiler still exist for those who need it, much like how they've been handling XP compatibility for the past several years. But I see no signs of MSVC going away any time soon; Microsoft has a very active and capable compiler team.
        • fomine3 5y ago
          But they also had active and capable browser engine team, isn't it?
• zetalyrae 5y ago
  >Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? I assumed the icc secret sauce was in the backend: deep knowledge of how each and every single operation is implemented in every uarch. Maybe they've written their own x86 backend for LLVM, and are using the rest of LLVM for IR->IR transformations and vectorization?
  • mshockwave 5y ago
    Exactly, many comments here are saying the difference is in LLVM IR ("middle-end") optimizations but IMHO more secrets are hidden in the backend. For example the latency of different instructions (and their operands) which has huge impact on the overall scheduling.
• lucozade 5y ago
  > Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? They're not upstreaming all their optimisations. I'd be surprised if they upstreamed all their FPGA support as well.
  • zozbot234 5y ago
    > They're not upstreaming all their optimisations That's quite reassuring for users of LLVM on non-Intel hardware, where ICC "optimisations" turn into pessimisations.
• pjmlp 5y ago
  Because not everything on icc is going to be upstreamed to clang, thanks license. It is not like clang is enjoying C++ Builder RAD abilities, PS 4 and 5 optimizations, or bitcode format used by watchOS.
  • ytch 5y ago
    Yeah, I guess LLVM is preferred mostly because license. Companies can keep their optimizations in secrets. Just like why Playststion's OS is based on BSD.
    • glangdale 5y ago
      LLVM is also preferred because it has much cleaner internals than gcc (although gcc has gotten hugely better over the years). And of course, all production compilers become monumentally complex over the years (I once worked with Open64 - gah).
    • floatboth 5y ago
      It's nearly impossible to keep optimizations secret. They are the easiest thing in the world to reverse engineer: just look at the output assembly. (And you can't exactly output obfuscated assembly because that would make the performance worse, nullifying the benefits of the optimizations.)
      • simondotau 5y ago
        Though in a practical sense, if you've done the work of implementing useful optimisations and keep them closed source, it's not necessarily a trivial matter for others to recognise and replicate how exactly your optimisation is implemented, when it can be used, when it can't be, etc.
      • dragontamer 5y ago
        I don't get it. Looking at output assembly language won't tell me anything about the algorithms behind solving the register allocation problem (aka: live data problem, which is a knapsack problem and/or graph-coloring problem IIRC). I'd be able to see that yes, compilers are good at deciding which registers should hold which data. But that's not sufficient at actually learning how the algorithm / register selection process works.
• MauranKilom 5y ago
  > Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? From the blog post: "Not all our optimization techniques get upstreamed—sometimes because they are too new, sometimes because they are very specific for Intel architecture. This is to be expected and is consistent with other compilers that have adopted LLVM." I don't see any good technical reason in this marketing language though, tbh: - "Our optimizations are too new" -> So put them behind a feature flag when upstreaming? And why inflict them on icx customers if they are "too new"? What does that even mean? - "Our optimizations are architecture specific" -> ...yes? Emitting good architecture-specific code is the whole point of an optimizing compiler? How is that an argument against upstreaming? - "Other compilers also don't upstream everything" -> That's a non-argument. I get it, there's no money to be made in just implementing all your optimizations in clang directly. But these reasons (together with the repeated emphasis of how they do contribute to LLVM) seem silly. To be clear, I'm all for Intel helping improve LLVM, but the technical arguments for maintaining a separate commercial version don't convince me at all.
  • formerly_proven 5y ago
    > I get it, there's no money to be made in just implementing all your optimizations in clang directly. ICC Classic is legacy/dead and also free now. The LLVM-based DPC++ compilers are free as well. These are only making money indirectly and through support contracts.
    • pjmlp 5y ago
      Yeah, but if you give all the golden eggs away, others can offer support contracts as well.
      • bluGill 5y ago
        They can, but who knows more about the issue in question, Intel who designed it, or a third party? This is also a curse to Intel though: they need to ensure their people actually know something, level one support with a bad script and no access to anyone with more ability will get caught quickly when the third party offers better support and generally can figure things out. There are pros and cons for sure. I'm not sure what it best.
• knxl 5y ago
  > Why not just use clang? Because clang is painful to use.
• deleted 5y ago
  [deleted]
• nsizx 5y ago
  GCC still has time to relicence if they want to survive.
  • GuB-42 5y ago
    Why would GCC relicense? It exists for the license, not the other way around. The entire point of GCC and the GNU project is to have an entire system with only free software, and the way to achieve that is not by allowing in more proprietary code. Let GCC die if it has to die, but changing the license would make it meaningless.
• simondotau 5y ago
  LLVM is a somewhat modular system. If Microsoft decided to build their own MSVC front end and AMD decided to build their own AMD64 back end, and Intel decided to build their own special set of x64 optimisers, is it really a monoculture? That sounds more like the GNU form of real software diversity—where you can make your own perfect tool by assembling it from parts.
  • ainar-g 5y ago
    > and AMD decided to build their own AMD64 back end They kind of already did. And it's on LLVM, too. https://developer.amd.com/amd-aocc/ https://developer.amd.com/amd-aocc/
• mumblemumble 5y ago
  The recent CPPCast episode on LFortran might shed some light on that? https://cppcast.com/lfortran/ https://cppcast.com/lfortran/ In it, the guest talks about how he couldn't rely on LLVM for things like optimizing array operations; LLVM apparently does a poor job of that so he had to implement his own. Given that one of the key selling points of Intel's compiler is that it does a better job with SIMD optimizations, it may be exactly the same story here.
  • jabl 5y ago
    Without listening to that podcast, I'm gonna go out on a limb and say this is a slightly Fortran-specific problem (or at least, not at problem encountered for C or C++), namely how to optimize Fortran array expressions. The LLVM IR doesn't understand array operations, so the Fortran frontend must 'scalarize' the array expressions, that is, turn them into the equivalent loops. Only after that can the LLVM middle and back-ends try to vectorize that scalar IR for execution on SIMD (or vector, or GPU) HW. The problem is that this scalarization loses some information, and thus for good performance on array code the Fortran frontend must implement some optimizations on array operations before scalarizing. There is an LLVM subproject called MLIR (https://mlir.llvm.org/ https://mlir.llvm.org/ ) that aims to build a higher level IR that understands arrays, and can be useful for things like optimizing deep learning graphs, but also things like Fortran frontends could make use of it. AFAIK the flang Fortran project aims to make use of it, but I haven't followed development that closely.
• frjalex 5y ago
  I'd imagine it'd be hard for MSVC and gcc to fade away --- gcc has some notable architectural differences from llvm (such as having multiple, layered IRs) and on some optimizations gcc is stronger. While for MSVC they target Microsoft's own ABI. Unlike other technologies that already feature a monocultural landscape I guess it's fair to say there's no one, single, best way to design a compiler that accounts for the wide-ranging differences of backend architectures and frontend languages (in addition, when you compare the costs of developing a brand new compiler with say, developing a new CPU architecture, you'll find the price associated with the former is much more affordable, and might be reasonable under different circumstances).
• spookthesunset 5y ago
  I mean GCC kinda picked their path back when they made it hard to be modular. The market has spoken and looks like LLVM made the right call.
• lhorie 5y ago
  Is gcc really starting to fade away? Wasn't Rust working on some backend interop with it? That shiny cool Cosmopolitan thingie was also built on top of it IIRC. I was also under the impression GCC still outputs better asm than LLVM overall. Conversely, I recall reading the zig team ran into some woes with the latest LLVM release, and that there's a lot of churn in LLVM APIs from version to version. (I'm legitimately curious)
• fay59 5y ago
  I like to think of LLVM as a piece of infrastructure, like neutral fiber wiring that any ISP is allowed to use. From that perspective, I’m a lot less concerned about having few options that I am about browsers. Although the diversity of C/C++ compilers is descending, the number of compiler backends in general is still pretty high (Go, .NET compilers & runtimes, Java compilers & runtimes, JS engines, etc), and LLVM can’t fill all the niches. I don’t think that we’re at a point where research is stifled.
  • deleted 5y ago
    [deleted]
• phendrenad2 5y ago
  Everyone says software monocultures are bad, without evidence. In fact, there seems to be evidence against this: the Linux kernel.
  • zamadatix 5y ago
    The Linux kernel isn't a monoculture yet. For example there is no indication Apple or the BSDs are going to stop developing their kernels nor is there indication Windows is dropping NT and most anything can/is easily moved between them (particularly the *NIX kernels) still. That doesn't mean there are certain places the only choice is the Linux kernel but that alone isn't enough to make it a monoculture in this sense of nearing domination of the space. Browsers are the most oft cited example of monoculture issues be it the old days with IE or the new days with Chrome, I'm surprised you haven't run across comments on that one over the years.
    • phendrenad2 5y ago
      Linux powers most of the internet, most mobile devices, and most embedded and IoT devices. Maybe it's not a complete monopoly, but it's close.
      • pjmlp 5y ago
        Except it doesn't, go check termux's future on Android, as its developers refuse to adopt the Java APIs that are actually what it public on Android (Linux kernel syscalls aren't a public API). https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis