25 ms·

Julia is incredibly fascinating for me as a language to observe, although I haven't got the time/patience to try it out yet. Its language design seems incredibl

Julia is incredibly fascinating for me as a language to observe, although I haven't got the time/patience to try it out yet. Its language design seems incredibly progressive and yet pragmatic: they've repopularized dynamic dispatch (which makes perfect sense in a mathematics-oriented language), and has a unique mix of dynamic and static typing that seems perfect in paper. In practice, Julia seems to suffer from the initial architectural decisions that the creators has made when the language was young - the biggest which is its heavy dependence on LLVM. This is a problem since LLVM is mainly used for static compilation of code for languages like C++/Rust/Zig and not with dynamic execution - its included JIT is famous for being unreasonably slow. Even the dev seems to know this but they don't seem to have that much choice - since too much of their codebase is dependent on it. (For example: https://discourse.julialang.org/t/jeff-bezanson-remarks-on-llvm-getting-slower-and-slower/39637 https://discourse.julialang.org/t/jeff-bezanson-remarks-on-l... - LLVM codegen keeps getting slower, which in turn cancels out all the little optimizations they can do for the language) It's a language that seems so perfect on paper but suffers from its real-world implementation - and therefore captivates me in a special way. Some major architectural overhaul might be a much better move (such as a fallback bytecode interpreter independent from LLVM) - but it's definitely going to be a major effort.

StefanKarpinski 5y ago
Using LLVM is not exactly an indelible architectural decision — switching to a bespoke JIT would be entirely possible, it’s just not worth it yet. Moreover, if you want to generate world-class high speed code, you really need something like LLVM. So yes, it’s a bit of a drag but it’s also a massive enabler of critical performance. That’s the real reason the project continues to use it. There are a number of approaches to reducing latency further, which are being pursued. The most promising current avenue is better tooling around system images (compiled executables with additional functionality beyond the core language pre-loaded): generating them faster, generating them incrementally (load one, add a few things and produce another), and generating them automatically for the set of packages in the current active project (not feasible until the first two are done). That will give an experience comparable to compiled languages.
- neolog 5y ago
  How much communication is there between the Julia compiler team and the LLVM team? I don't get the impression LLVM has been very sensitive to Julia's needs so far.
  - stabbles 5y ago
    Not an answer to the question, but a fun fact: there is a julia source file in the llvm project [1] [1] https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/libc/AOR_v20.02/math/tools/remez.jl https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee...
  - StefanKarpinski 5y ago
    Quite a bit: several of the Julia compiler team are LLVM maintainers and contributors. LLVM has started to track compile time, so that's gotten a bit better with recent releases. Making noise about compile time was mainly to get the LLVM project to start paying attention to compile time, which they now have, so mission accomplished — as long as they stop completely allowing latency to degenerate, it's ok. LLVM is never going to be fast at compiling code (and if we used something else that was as good at producing fast code, it would almost certainly also be slow), so avoiding putting LLVM in the fast path is always going to be necessary to make more latency improvements.
    - neolog 5y ago
      That's great to hear. I found some info about it which looks promising. https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
- canadianfella 5y ago
  Graal may be a good option for Julia. It would take a huge amount of work.
BadInformatics 5y ago
You may be interested in the current initiative around compiler plugins [1]. One of the explicit design goals is offload to alternative backends like GPUs or Wasm, but you could see how that would extend to something like Cranelift as well. That said, LLVM codegen performance is very much a tail wagging the dog thing, and I wish upstream put a significantly larger focus on it [2] [1] https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view [2] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html

StefanKarpinski 5y ago

Using LLVM is not exactly an indelible architectural decision — switching to a bespoke JIT would be entirely possible, it’s just not worth it yet. Moreover, if you want to generate world-class high speed code, you really need something like LLVM. So yes, it’s a bit of a drag but it’s also a massive enabler of critical performance. That’s the real reason the project continues to use it. There are a number of approaches to reducing latency further, which are being pursued. The most promising current avenue is better tooling around system images (compiled executables with additional functionality beyond the core language pre-loaded): generating them faster, generating them incrementally (load one, add a few things and produce another), and generating them automatically for the set of packages in the current active project (not feasible until the first two are done). That will give an experience comparable to compiled languages.

neolog 5y ago
How much communication is there between the Julia compiler team and the LLVM team? I don't get the impression LLVM has been very sensitive to Julia's needs so far.
- stabbles 5y ago
  Not an answer to the question, but a fun fact: there is a julia source file in the llvm project [1] [1] https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/libc/AOR_v20.02/math/tools/remez.jl https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee...
- StefanKarpinski 5y ago
  Quite a bit: several of the Julia compiler team are LLVM maintainers and contributors. LLVM has started to track compile time, so that's gotten a bit better with recent releases. Making noise about compile time was mainly to get the LLVM project to start paying attention to compile time, which they now have, so mission accomplished — as long as they stop completely allowing latency to degenerate, it's ok. LLVM is never going to be fast at compiling code (and if we used something else that was as good at producing fast code, it would almost certainly also be slow), so avoiding putting LLVM in the fast path is always going to be necessary to make more latency improvements.
  - neolog 5y ago
    That's great to hear. I found some info about it which looks promising. https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
canadianfella 5y ago
Graal may be a good option for Julia. It would take a huge amount of work.

BadInformatics 5y ago

You may be interested in the current initiative around compiler plugins [1]. One of the explicit design goals is offload to alternative backends like GPUs or Wasm, but you could see how that would extend to something like Cranelift as well. That said, LLVM codegen performance is very much a tail wagging the dog thing, and I wish upstream put a significantly larger focus on it [2] [1] https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view [2] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html