6 ms·

LLVM is a trap. You bootstrap extra fast, you get all sorts of optimization passes and platforms for free, but you lose out on the ability to tune the final opt

LLVM is a trap. You bootstrap extra fast, you get all sorts of optimization passes and platforms for free, but you lose out on the ability to tune the final optimization passes and performance of the linking stages. I think we'll see cranelift take off in Rust quite soon, though I also think it wouldn't be the juggernaut of a language if they hadn't stuck with LLVM those early years. Go seems to have made the choice long ago to eschew outsourcing of codegen and linking and done well for it.

deleted 1y ago
[deleted]
OtomotO 1y ago
Huh, are there plans on using cranelift for release builds?
- veber-alex 1y ago
  No
- 01HNNWZ0MV43FF 1y ago
  If it's a small overhead I might
  - mmastrac 1y ago
    "While it does not have the aggressive optimization stance (or complexity) of larger compilers such as LLVM or gcc, its output is often not too far off: the same paper showed Cranelift generating code that ran ~2% slower than V8 (TurboFan) and ~14% slower than an LLVM-based system." -- https://cranelift.dev/ https://cranelift.dev/
    - azakai 1y ago
      The Cranelift website does have that quote, but the linked paper says > The resulting code performs on average 14% better than LLVM -O0, 22% slower than LLVM -O1, 25% slower than LLVM -O2, and 24% slower than LLVM -O3 So it is more like 24% slower, not 14%. Perhaps a typo (24/14), or they got the direction mixed up (it is +14 vs -24), or I'm reading that wrong? Regardless, those numbers are on a particular set of database benchmarks (TPC-H), and I wouldn't read too much into them.
      - mmastrac 1y ago
        Interesting. Thanks for those numbers. I'd be interested in trying some real-world applications myself.
      - dontlaugh 1y ago
        Even 14% would be unacceptably slow for a system language. I don’t think that means it’s not doable, though.
        goku12 1y ago
        The artifact's executions speed doesn't seem to be Cranelift's priority. They're instead focusing on compilation speed and security. Those are still useful in Rust for debug builds at least. That's when we need a quick turnaround time and as much verification as possible.
    - anematode 1y ago
      Besides the potential typo noted by another comment, I'd also note that the benchmarks are on a WebAssembly compiler, which has already gone through the LLVM wringer and thus undergone many high-level optimizations, including those reliant on alias analysis (which Cranelift is quite conservative on, iirc). I'd also imagine that the translation from LLVM IR to WASM discards some useful information that the LLVM backend could otherwise have used to generate better assembly. That's not to say Cranelift isn't a fantastic piece of tech, but I wouldn't take the "14%" or "24%" number at face value.
almostgotcaught 1y ago
[flagged]
- nine_k 1y ago
  Would be great to see any confirmation.
  - almostgotcaught 1y ago
    https://github.com/intel/llvm https://github.com/intel/llvm https://github.com/iree-org/llvm-project https://github.com/iree-org/llvm-project https://github.com/ROCm/llvm-project https://github.com/ROCm/llvm-project https://github.com/apple/swift-llvm https://github.com/apple/swift-llvm https://github.com/dotnet/llvm-project https://github.com/dotnet/llvm-project https://github.com/espressif/llvm-project https://github.com/espressif/llvm-project should i keep going?
    - anttiharju 1y ago
      Checking the first one > Intel staging area for llvm.org contribution. Home for Intel LLVM-based projects. Seems like they use it to contribute to upstream which is business as usual?
      - almostgotcaught 1y ago
        what exactly do you people think a fork is? hint: it's not a complete forever and ever and ever divergence. Edit: the concept of fork and hard fork are distinct. I specifically used the word fork
        IshKebab 1y ago
        Fork without context usually means a hard fork.
        almostgotcaught 1y ago
phplovesong 1y ago
Both Go and Ocaml have really, really fast compilers. They did the works from the get go, and now wont have to pay the price. I cant see myself ever again working on a system with compile times that take over a minute or so (prod build not counting). I wish more projects would have they own "dev" compiler that would not do all the shit llvm does, and only use llvm for the final prod build.
- deleted 1y ago
  [deleted]
- pjmlp 1y ago
  They show a return to how fast compilers used to be, before C and C++ took over the zeitgeist of compilation times. Eiffel, Common Lisp, Java and .NET (C#, F#, VB) are other examples, where we can enjoy fast development loops. By combining JIT and AOT workflows, you can get best of both worlds. I think the main reason this isn't as common is the effort that it takes to keep everything going. I am on the same camp regarding build times, as I keep looking for my Delphi experience when not using it.
  - debugnik 1y ago
    As much as I love F#, I wouldn't add it to a list of fast compilers; although I really appreciate that it supports actual file-scoped optimizations and features for compile-time inlining.
    - rafaelmn 1y ago
      I wouldn't even put C# in there - minute builds are like nothing unusual, and my only experience with Java is Android but that was really bad too. They aren't C++ levels bad, but they are slow enough to be distracting/flow breaking. Something like dart/flutter or even TS and frontend with hot reload is much leaner. Comparing to fully dynamic languages is kind of unfair in that regard. I did not try Go yet but from what I've read (and also seeing the language design philosophy) I suspect it's faster than C#/Java.
dbtc 1y ago
How is it a trap if languages are able to move away?
- pjmlp 1y ago
  Not all do, some stick with their decision to live with LLVM, e.g. Swift, Julia, Mojo,...
  - akkad33 1y ago
    But isn't there a reason why so many start with LLVM ? It's highly optimised. I think mojo is not LLVM but mlir
    - pjmlp 1y ago
      It is the modern version of a compiler construction toolkit, which by the way isn't a new idea, even though so many think LLVM was the first one, One example from 1980s, there are others to pick from as example, https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit So naturally a way to quickly reach the stage where a compiler is avaible for a brand new language, without having to write all compiler stages by hand. A kind of middleware for writing compilers, if you wish. MLIR is part of LLVM tooling, is the evolution of LLVM IR.
    - melodyogonna 1y ago
      Mojo uses mlir for high-level ir and most optimizations but codegen is still done with llvm, albeit in unconventional manner.
pjmlp 1y ago
Additionally any language that wants to be a C++ replacement, keeps a dependency on C++ as long as LLVM is part of its tooling infrastructure. For me beyond the initial adoption hump, programming languages should bootstrap themselves, if nothing else, reduces the urban myth that C or C++ have to always be part of the equation. Not at all, in most cases it is a convenience, writing usable compilers takes time, and it is an easy way to get everything else going, especially when it comes to porting across multiple platforms. However that doesn't make them magical tools, without which is impossible to write compilers. That is one area where I am fully on board with Go team's decisions.
goodpoint 1y ago
GCC is the way.
nikic 1y ago
> LLVM is a trap. Is it? I think Rust is a great showcase for why it isn't. Of course it depends somewhat on your compiler implementation approach, but actual codegen-to-LLVM tends to only be a tiny part of the compiler, and it is not particularly hard to replace it with codegen-to-something-else if you so desire. Which is why there is now codegen_cranelift, codegen_gcc, etc. The main "vendor lock-in" LLVM has is if you are exposing the tens of thousands of vendor SIMD intrinsics, but I think that's inherent to the problem space. Of course, whether you're going to find another codegen backend (or are willing to write one yourself) that provides similar capabilities to LLVM is another question... > You bootstrap extra fast, you get all sorts of optimization passes and platforms for free, but you lose out on the ability to tune the final optimization passes and performance of the linking stages. You can tune the pass pipeline when using LLVM. If your language is C/C++ "like", the default pipeline is good enough that many such users of LLVM don't bother, but languages that differ more substantially will usually use fully custom pipelines. > I think we'll see cranelift take off in Rust quite soon, though I also think it wouldn't be the juggernaut of a language if they hadn't stuck with LLVM those early years. I'd expect that most (compiled) languages do well to start with an LLVM backend. Having a tightly integrated custom backend can certainly be worthwhile (and Go is a great success story in that space), but it's usually not the defining the feature of the language, and there is a great opportunity cost to implementing one.
- crawshaw 1y ago
  It is a “trap” in the sense that it limits the design space for your language by forcing some of the choices implicit in C++. Rust went with slow build times like C++ and so was not held back in this dimension by LLVM. Nothing about LLVM is a trap for C++ as that is what it was designed for.
bfrog 1y ago
I hope cranelift continues to grow too. LLVM tragically has become fork hell. Every cpu vendor now seems to have a fork with enhancements for their cpu arch in some closed source package. It’s hellish as soon as you want to use another language frontend or find the inevitable compiler bug.
- pjmlp 1y ago
  That is the magic of MIT like licenses. How much do you think the BSDs get back from Apple and Sony?
whatshisface 1y ago
A trap? New language projects would never be able to develop the architecture support and optimizer. There's nothing new in the linking stage you couldn't submit as a patch to LLVM upstream.
EasyMark 1y ago
Seems more like a tr-ade off than a tr-ap. Everything has a price. I think LLVM is well worth the tradeoffs for all the stuff that it gives you. I'm sure that some better tech will replace it but calling it a trap seems like an exaggeration, it seems to work well enough for even the biggest companies and countries in the world.

deleted 1y ago

[deleted]

OtomotO 1y ago

Huh, are there plans on using cranelift for release builds?

veber-alex 1y ago
No
01HNNWZ0MV43FF 1y ago
If it's a small overhead I might
- mmastrac 1y ago
  "While it does not have the aggressive optimization stance (or complexity) of larger compilers such as LLVM or gcc, its output is often not too far off: the same paper showed Cranelift generating code that ran ~2% slower than V8 (TurboFan) and ~14% slower than an LLVM-based system." -- https://cranelift.dev/ https://cranelift.dev/
  - azakai 1y ago
    The Cranelift website does have that quote, but the linked paper says > The resulting code performs on average 14% better than LLVM -O0, 22% slower than LLVM -O1, 25% slower than LLVM -O2, and 24% slower than LLVM -O3 So it is more like 24% slower, not 14%. Perhaps a typo (24/14), or they got the direction mixed up (it is +14 vs -24), or I'm reading that wrong? Regardless, those numbers are on a particular set of database benchmarks (TPC-H), and I wouldn't read too much into them.
    - mmastrac 1y ago
      Interesting. Thanks for those numbers. I'd be interested in trying some real-world applications myself.
    - dontlaugh 1y ago
      Even 14% would be unacceptably slow for a system language. I don’t think that means it’s not doable, though.
      - goku12 1y ago
        The artifact's executions speed doesn't seem to be Cranelift's priority. They're instead focusing on compilation speed and security. Those are still useful in Rust for debug builds at least. That's when we need a quick turnaround time and as much verification as possible.
  - anematode 1y ago
    Besides the potential typo noted by another comment, I'd also note that the benchmarks are on a WebAssembly compiler, which has already gone through the LLVM wringer and thus undergone many high-level optimizations, including those reliant on alias analysis (which Cranelift is quite conservative on, iirc). I'd also imagine that the translation from LLVM IR to WASM discards some useful information that the LLVM backend could otherwise have used to generate better assembly. That's not to say Cranelift isn't a fantastic piece of tech, but I wouldn't take the "14%" or "24%" number at face value.

almostgotcaught 1y ago

[flagged]

nine_k 1y ago
Would be great to see any confirmation.
- almostgotcaught 1y ago
  https://github.com/intel/llvm https://github.com/intel/llvm https://github.com/iree-org/llvm-project https://github.com/iree-org/llvm-project https://github.com/ROCm/llvm-project https://github.com/ROCm/llvm-project https://github.com/apple/swift-llvm https://github.com/apple/swift-llvm https://github.com/dotnet/llvm-project https://github.com/dotnet/llvm-project https://github.com/espressif/llvm-project https://github.com/espressif/llvm-project should i keep going?
  - anttiharju 1y ago
    Checking the first one > Intel staging area for llvm.org contribution. Home for Intel LLVM-based projects. Seems like they use it to contribute to upstream which is business as usual?
    - almostgotcaught 1y ago
      what exactly do you people think a fork is? hint: it's not a complete forever and ever and ever divergence. Edit: the concept of fork and hard fork are distinct. I specifically used the word fork
      - IshKebab 1y ago
        Fork without context usually means a hard fork.
        almostgotcaught 1y ago

phplovesong 1y ago

Both Go and Ocaml have really, really fast compilers. They did the works from the get go, and now wont have to pay the price. I cant see myself ever again working on a system with compile times that take over a minute or so (prod build not counting). I wish more projects would have they own "dev" compiler that would not do all the shit llvm does, and only use llvm for the final prod build.

deleted 1y ago
[deleted]
pjmlp 1y ago
They show a return to how fast compilers used to be, before C and C++ took over the zeitgeist of compilation times. Eiffel, Common Lisp, Java and .NET (C#, F#, VB) are other examples, where we can enjoy fast development loops. By combining JIT and AOT workflows, you can get best of both worlds. I think the main reason this isn't as common is the effort that it takes to keep everything going. I am on the same camp regarding build times, as I keep looking for my Delphi experience when not using it.
- debugnik 1y ago
  As much as I love F#, I wouldn't add it to a list of fast compilers; although I really appreciate that it supports actual file-scoped optimizations and features for compile-time inlining.
  - rafaelmn 1y ago
    I wouldn't even put C# in there - minute builds are like nothing unusual, and my only experience with Java is Android but that was really bad too. They aren't C++ levels bad, but they are slow enough to be distracting/flow breaking. Something like dart/flutter or even TS and frontend with hot reload is much leaner. Comparing to fully dynamic languages is kind of unfair in that regard. I did not try Go yet but from what I've read (and also seeing the language design philosophy) I suspect it's faster than C#/Java.

dbtc 1y ago

How is it a trap if languages are able to move away?

pjmlp 1y ago
Not all do, some stick with their decision to live with LLVM, e.g. Swift, Julia, Mojo,...
- akkad33 1y ago
  But isn't there a reason why so many start with LLVM ? It's highly optimised. I think mojo is not LLVM but mlir
  - pjmlp 1y ago
    It is the modern version of a compiler construction toolkit, which by the way isn't a new idea, even though so many think LLVM was the first one, One example from 1980s, there are others to pick from as example, https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit So naturally a way to quickly reach the stage where a compiler is avaible for a brand new language, without having to write all compiler stages by hand. A kind of middleware for writing compilers, if you wish. MLIR is part of LLVM tooling, is the evolution of LLVM IR.
  - melodyogonna 1y ago
    Mojo uses mlir for high-level ir and most optimizations but codegen is still done with llvm, albeit in unconventional manner.

pjmlp 1y ago

Additionally any language that wants to be a C++ replacement, keeps a dependency on C++ as long as LLVM is part of its tooling infrastructure. For me beyond the initial adoption hump, programming languages should bootstrap themselves, if nothing else, reduces the urban myth that C or C++ have to always be part of the equation. Not at all, in most cases it is a convenience, writing usable compilers takes time, and it is an easy way to get everything else going, especially when it comes to porting across multiple platforms. However that doesn't make them magical tools, without which is impossible to write compilers. That is one area where I am fully on board with Go team's decisions.

goodpoint 1y ago

GCC is the way.

nikic 1y ago

> LLVM is a trap. Is it? I think Rust is a great showcase for why it isn't. Of course it depends somewhat on your compiler implementation approach, but actual codegen-to-LLVM tends to only be a tiny part of the compiler, and it is not particularly hard to replace it with codegen-to-something-else if you so desire. Which is why there is now codegen_cranelift, codegen_gcc, etc. The main "vendor lock-in" LLVM has is if you are exposing the tens of thousands of vendor SIMD intrinsics, but I think that's inherent to the problem space. Of course, whether you're going to find another codegen backend (or are willing to write one yourself) that provides similar capabilities to LLVM is another question... > You bootstrap extra fast, you get all sorts of optimization passes and platforms for free, but you lose out on the ability to tune the final optimization passes and performance of the linking stages. You can tune the pass pipeline when using LLVM. If your language is C/C++ "like", the default pipeline is good enough that many such users of LLVM don't bother, but languages that differ more substantially will usually use fully custom pipelines. > I think we'll see cranelift take off in Rust quite soon, though I also think it wouldn't be the juggernaut of a language if they hadn't stuck with LLVM those early years. I'd expect that most (compiled) languages do well to start with an LLVM backend. Having a tightly integrated custom backend can certainly be worthwhile (and Go is a great success story in that space), but it's usually not the defining the feature of the language, and there is a great opportunity cost to implementing one.

crawshaw 1y ago
It is a “trap” in the sense that it limits the design space for your language by forcing some of the choices implicit in C++. Rust went with slow build times like C++ and so was not held back in this dimension by LLVM. Nothing about LLVM is a trap for C++ as that is what it was designed for.

bfrog 1y ago

I hope cranelift continues to grow too. LLVM tragically has become fork hell. Every cpu vendor now seems to have a fork with enhancements for their cpu arch in some closed source package. It’s hellish as soon as you want to use another language frontend or find the inevitable compiler bug.

pjmlp 1y ago
That is the magic of MIT like licenses. How much do you think the BSDs get back from Apple and Sony?

whatshisface 1y ago

A trap? New language projects would never be able to develop the architecture support and optimizer. There's nothing new in the linking stage you couldn't submit as a patch to LLVM upstream.

EasyMark 1y ago

Seems more like a tr-ade off than a tr-ap. Everything has a price. I think LLVM is well worth the tradeoffs for all the stuff that it gives you. I'm sure that some better tech will replace it but calling it a trap seems like an exaggeration, it seems to work well enough for even the biggest companies and countries in the world.