Live data from Hacker News

We accidentally built an LLVM compiler for Jax

iza.ac

21–26 of 26 posts

Re: We accidentally built an LLVM compiler for Jax

#21
post #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.

Ah, I'm behind the times.

Re: We accidentally built an LLVM compiler for Jax

#22
1. Why not Julia? IIRC, some/all of this already exists in that ecosystem.

> Something to note is that quantum algorithms are never purely quantum. There is a tonne of classical processing needed to get inputs ready, post-process outputs, and even construct and represent the quantum circuits themselves.

2. Did you face any problems for the 'surrounding' areas by JAX imposing the limitation of pure functions?

Re: We accidentally built an LLVM compiler for Jax

#23

1. Why not Julia? IIRC, some/all of this already exists in that ecosystem. > Something to note is that quantum algorithms are never purely quantum. There is a tonne of classical processing needed to get inputs ready, post-process outputs, and even construct and represent the quantum circuits themselves. 2. Did you face any problems for the 'surrounding' areas by JAX imposing the limitation of pure functions?

Main reason is that the quantum computing/scientific research user base is still very Python entrenched

Re: We accidentally built an LLVM compiler for Jax

#24

1. Why not Julia? IIRC, some/all of this already exists in that ecosystem. > Something to note is that quantum algorithms are never purely quantum. There is a tonne of classical processing needed to get inputs ready, post-process outputs, and even construct and represent the quantum circuits themselves. 2. Did you face any problems for the 'surrounding' areas by JAX imposing the limitation of pure functions?

Main reason is that the quantum computing/scientific research user base is still very Python entrenched

Sure, but if you're writing in the JAX DSL you've already abandoned python.

Re: We accidentally built an LLVM compiler for Jax

#25

Earlier quoted context omitted.

Main reason is that the quantum computing/scientific research user base is still very Python entrenched

Sure, but if you're writing in the JAX DSL you've already abandoned python.

I mean, not really? Most Jax code is only marginally more restrictive than numpy, and most of the annoyances I have with Jax are shared with numpy.

And having spent too much of my life writing some extremely high performance physics code, 99% of the code complexity comes from the stupid stuff, like handling configuration and IO and restarting. Python handles that stuff great. Oh, and tests. Ever tried to write unit tests in Fortran? You'll hug python tight and promise it you'll never leave again.

Re: We accidentally built an LLVM compiler for Jax

#26

Earlier quoted context omitted.

Sure, but if you're writing in the JAX DSL you've already abandoned python.

I mean, not really? Most Jax code is only marginally more restrictive than numpy, and most of the annoyances I have with Jax are shared with numpy. And having spent too much of my life writing some extremely high performance physics code, 99% of the code complexity comes from the stupid stuff, like handling configuration and IO and restarting. Python handles that stuff great. Oh, and tests. Ever tried to write unit t…

It proves the point. Numpy still doesn't have the semantics of a full programming language like Mojo/C++/Julia.
Post reply on HN