Live data from Hacker News

We accidentally built an LLVM compiler for Jax

iza.ac

11–20 of 26 posts

Re: We accidentally built an LLVM compiler for Jax

#11

This is actually really neat, I had an agent create some experimental probes and check out whats going on here and it seems like a pretty cool project. I'm gonna need to digest how this might be useful but I think this could be cool for some sort of FPGA uses perhaps. > this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations for linear algebra on GPUs and TPUs…

Just for receipts I span up a basic test for XLA:

Can you figure out that 16 matrix vector multiplications into a concatenate is the same as concatenating first into a matrix matrix operation which can go on the GEMM. This is like the most basic thing you can imagine doing.

Turns out no it doesn't and there is a 23% performance difference by moving the concatenate up in the python code in my specific test.

Not to say that it didn't recognize it. I had an agent look at the XLA and the graph actually does a partial fusion into a sum and stack. But does not realize the whole thing is just a GEMM.

In more complicated examples the differences you can get can be much larger.

Re: We accidentally built an LLVM compiler for Jax

#12

Neat. XLA predates MLIR. Interesting stories there. You'd have to stop by the Bay Area LLVM monthly meetup to hear them. :-X > So if XLA already uses LLVM, why is our approach different? Uses MLIR, XLA does not. > So… what is the point? > Honestly? We aren’t entirely sure yet. > Let me be perfectly clear: this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations…

> Uses MLIR, XLA does not. https://github.com/search?q=repo%3Aopenxla%2Fxla+mlir&type=c... > 1.5k files you're behind the times. XLA moved over probably ~2 years ago - "Captain Awesome" eventually relented.

This happened “despite”. MLIR is definitely a productivity boost and yet, the progress in adoption has been stalled many times by one aforementioned charismatic leader. It’s truly mind boggling that a personal spat would influence roadmap of an entire org for years.

Re: We accidentally built an LLVM compiler for Jax

#13

This is actually really neat, I had an agent create some experimental probes and check out whats going on here and it seems like a pretty cool project. I'm gonna need to digest how this might be useful but I think this could be cool for some sort of FPGA uses perhaps. > this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations for linear algebra on GPUs and TPUs…

Just for receipts I span up a basic test for XLA: Can you figure out that 16 matrix vector multiplications into a concatenate is the same as concatenating first into a matrix matrix operation which can go on the GEMM. This is like the most basic thing you can imagine doing. Turns out no it doesn't and there is a 23% performance difference by moving the concatenate up in the python code in my specific test. Not to say…

[deleted]

Re: We accidentally built an LLVM compiler for Jax

#14
post #7

Earlier quoted context omitted.

> Uses MLIR, XLA does not. https://github.com/search?q=repo%3Aopenxla%2Fxla+mlir&type=c... > 1.5k files you're behind the times. XLA moved over probably ~2 years ago - "Captain Awesome" eventually relented.

lol, good luck to amazon

indeed

Re: We accidentally built an LLVM compiler for Jax

#16

Neat. XLA predates MLIR. Interesting stories there. You'd have to stop by the Bay Area LLVM monthly meetup to hear them. :-X > So if XLA already uses LLVM, why is our approach different? Uses MLIR, XLA does not. > So… what is the point? > Honestly? We aren’t entirely sure yet. > Let me be perfectly clear: this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations…

XLA uses MLIR very much, the interface to it is StableHLO, which is a MLIR dialect.

Re: We accidentally built an LLVM compiler for Jax

#18

This is actually really neat, I had an agent create some experimental probes and check out whats going on here and it seems like a pretty cool project. I'm gonna need to digest how this might be useful but I think this could be cool for some sort of FPGA uses perhaps. > this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations for linear algebra on GPUs and TPUs…

Just for receipts I span up a basic test for XLA: Can you figure out that 16 matrix vector multiplications into a concatenate is the same as concatenating first into a matrix matrix operation which can go on the GEMM. This is like the most basic thing you can imagine doing. Turns out no it doesn't and there is a 23% performance difference by moving the concatenate up in the python code in my specific test. Not to say…

Is this surprising? My experience with compilers from the old days of Fortran is that they care about correctness first, performance second. I used to spend plenty of time rewriting algorithms so they ended up in a form the compiler would like.

I think this is a great area for LLMs. You write the correct physics code, the LLM analyzes intent and goes back and forth with the compiler and your correct code to rewrite it in something that emits performant code

Re: We accidentally built an LLVM compiler for Jax

#19
post #15

> Plus, no need to build XLA using Bazel either! You’re welcome. I don't get it, Bazel is incredible.

Many people find it complicated.

It is. The question is if it's worth the complication. The cheeky answer would be to say it is, but that's not universally true.

Re: We accidentally built an LLVM compiler for Jax

#20

Neat. XLA predates MLIR. Interesting stories there. You'd have to stop by the Bay Area LLVM monthly meetup to hear them. :-X > So if XLA already uses LLVM, why is our approach different? Uses MLIR, XLA does not. > So… what is the point? > Honestly? We aren’t entirely sure yet. > Let me be perfectly clear: this is not going to beat XLA for standard deep learning workloads. XLA has years of hyper-specific optimizations…

> Uses MLIR, XLA does not. https://github.com/search?q=repo%3Aopenxla%2Fxla+mlir&type=c... > 1.5k files you're behind the times. XLA moved over probably ~2 years ago - "Captain Awesome" eventually relented.

Yeah, guess I should have used the past tense there.
Post reply on HN