Cranelift: a faster alternative to LLVM

The rust compiler can now build with either LLVM or cranelift. cranelift is not nearly as developed as LLVM (e.g., SIMD is only partially supported), but has the benefit of building quite a bit faster, and from this blog post, the plan for rust is to use it to speed up debug builds.

https://jason-williams.co.uk/a-possible-new-backend-for-rust

Because a lot of work in Julia is going into reducing compile times, I thought some people here might be interested. It would almost certainly be a lot of work for Julia to add this as a backend, but might be worth considering at some point.

Cheers, and be well,

Kevin

8 Likes

As far as I know, LLVM is not considered a major part of compile time for julia (mostly inference and specialization). As those get faster though, this could become pretty important.

2 Likes

I heard about another compiler based on LLVM - MLIR

6 Likes

In last Ask us everything Jeff Bezanson said that he has only two concers about Julia and second is that LLVM became slower and slower (at 8:45), but I don’t understand precisely nature of this problem. I mean, many diffrent things in LLVM can became slower.

Do you try contacted him and ask about that?

I’m not a compiler person, so I don’t know the reasons for it, but I have become pretty concerned with what has happened with the LLVM “ecosystem”. It seems like just about everything has its own patched version of the LLVM, and have to move heaven and earth to ever update their LLVM version, first because of the patching, but second because of the serious performance regressions that I have also heard Jeff and others mention a number of times. This has led to sort of the opposite of the situation we want: different things that use LLVM are incompatible. For example, has anyone tried a Rust-Julia interface? I haven’t seen one, as far as I know there are major technical obstacles to this, though it’s obviously something we should want. Another problem I’ve noticed is with the cling C++ interpreter which also uses a patched LLVM, which may be a major obstacle to the high energy physics community using Julia, which is pretty upsetting, because this is a community which would probably get pretty excited by it.

The reason I mention this here is: does anyone qualified to say so think that either cranelift or MLIR is a realistic candidate for addressing some of the issues that have caused this LLVM fracturing and incompatibility?

5 Likes

I don’t think that is true at all.

2 Likes

I’m very interested in this things, can you give me idea where I can read about it more?

Maybe you’re referring to a different kind of interface, but I’ve used the following package to call Julia functions from Rust with good results:

Calling Rust functions from Julia is of course even easier.

3 Likes

Interesting, perhaps I’m not understanding what I thought the issues were here. I’ve definitely read various things about difficulties in compatibility between different patched versions of LLVM, but I only have a vague idea of what those are. Would be great if someone who knows better could come along and give a more detailed explanation of what might happen in those cases.

1 Like

Clashing versions of LLVM is definitely an issue in the GPU world; I’ve encountered problems with both OpenCL.jl and our AMDGPU ROCm external libraries because the libraries they call into use a different LLVM build.

Also, MLIR can only really make compile times worse, because it first runs MLIR passes, and then runs all of our LLVM passes (although I could be wrong about this).

2 Likes

Sorry for necroing this thread but LLVM getting slower over time is starting to get some attention. You can read a very good blog post on this here https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html .

3 Likes