I have been very interested in the HVM since the first time it was posted on Github. One thing that has been sorely missing is a front-end for any realworld language. This will allow real comparisons of programs instead of tiny toys rewritten from Haskell to interactions nets.
Hi Victor — exciting work! For language designers interested in this system, is there a common reference for e.g. using it (for example, from a language + lowering pipeline in Rust)?
(Or perhaps that’s also what you alluded to in the next couple of months)
Exactly, we're working on a guide for language designers. And while HVM-Core (the repo I posted today) is the lowest IR, I believe most languages should actually compile to HVM-Lang (to be released), which is a higher-level AST that is more familiar and does a lot for you (so you don't need you to write your own conversions from your language to interaction combinators and back).
Exactly! Sorry if that sounded to be the case. We're first focusing on making the runtime as fast as possible. Next step is to support some simple toy lang (like a Haskell-like and a Python-like) for people to start using. Only then we can start compiling existing languages, which is a colossal task (due to languages like JS having a bajillion features).
Yes but wouldn't be great. The problem is that these ultra low level assembly languages actually throw away a lot of information that is useful to parallelism. Recursive functions are great for HVM, but when compiled to assembly, that structure is lost.
I suppose it’s not always lost, but the call graph needs to be inferred, and you might risk applying low-level optimisations that only apply to CPU, which may break the ability to infer the highly parallelizable structure in the high-level language. Compiling to CPU assembly is sort of a step back.
you guys should do erlang/ (or a elixir) pretty simple functional languages that already have a lot of ergonomics around concurrency and parallelism! that would be awesome :)
Very nice! I recall reading that the HVM has some semantic differences with the classic lambda-calculus, which resulted in different results for some programs. Would this be an issue when e.g. translating Haskell programs? (and/or is there some way to 'emulate' lambda calculus semantics?)
Also, are there any plans to get this working on non-Nvidia GPUs, e.g. with ROCm/HIP (which would hopefully be a straightforward translation, if AMD's software does its job) or OpenCL (more effort, but more portable)?
Good question! There are several implementations of the full λ-calculus on interaction nets; that isn't the problem. The problem is that these solutions always came up with a constant time slowdown, which made interaction nets even less practical. The thing is, HVM is getting so fast that we're almost at the point where we can just say damn it, eat that slowdown, and still be faster. So, optimization after optimization, we're kinda brute-forcing our way into supporting full lambdas in practice. And the best is that with some pre-processing steps (like EAL inference) we could compile Haskell to the fastest version when it is safe to do so - which is more often than you'd think!
Yes we're hiring GPU developers to optimize the current runtime (which still has a lot of room) and to extend support to more architectures. GPU developers aren't exactly cheap nowadays though lol. I blame OpenAI.
Keep digging! I love your project so much! My instincts tell me there can be really cool discoveries in this paradigm. It seems to mesh (ha) so well with so many problem domains.
So, could this be used to compile an OS, so it would mostly run on the GPU, and also say, python itself, perhaps V8, an an x86 emulator, stuff like that?
Yes that is the ultimate goal! Although that is obviously a far future. Currently we only have funding to provide a few toy languages, but hopefully the results will be good enough to draw attention so we can scale and broaden support to more and more languages!
I wish people would stop saying GPUs when they mean Nvidia GPUs. It’s like saying you’ve made a product for cars, but then it turns out it’s only for Mercedes cars.
I take it these "Interaction nets" won't be compilable from just any old python code? I can only imagine there are still some pretty heavy constraints around parallelism. Is the idea here that your python script would be SIMD?
The ultimate goal is indeed to compile any code to GPUs, but we can't change the logic of your program. It is just a bunch of sequential loops, there isn't much we can do about it! But you can still use a Python-like syntax to create highly parallel programs, specially if you like recursion or things like map, reduce, and working with trees/JSON in general.
Haskell is a complex language that would be very hard to target. What do you think of targeting the Haskell Core, a high-level intermediate representation that GHC uses? It is much simpler than Haskell itself and would preserve the opportunities for parallelization.
Yes that is the goal, but I'm not familiar enough with it to judge the complexity of such project. I do know GHCJS demanded tons of resource and efforts, so I do anticipate it will not be a simple task. That's why I want to support simpler languages like Elm and a Python-like language first...
This always seemed like a very interesting project; we need to get to the point where, if things can run in parallel, they must run in parallel to make software more efficient on modern cpu/gpu.
It won't attract funds, I guess, but it would be far more trivial to make this work with an APL or a Lisp/Scheme. There already is great research for APL[0] and looking at the syntax of HVM-core it seems it is rather easy to knock up a CL DSL. If only there were more hours in a day.
31 comments
[ 4.2 ms ] story [ 71.0 ms ] thread(Or perhaps that’s also what you alluded to in the next couple of months)
Both elixir and erlang (and all Beam languages elaborate to Core Erlang)
Also, are there any plans to get this working on non-Nvidia GPUs, e.g. with ROCm/HIP (which would hopefully be a straightforward translation, if AMD's software does its job) or OpenCL (more effort, but more portable)?
Yes we're hiring GPU developers to optimize the current runtime (which still has a lot of room) and to extend support to more architectures. GPU developers aren't exactly cheap nowadays though lol. I blame OpenAI.
https://blog.pimaker.at/texts/rvc1/
It won't attract funds, I guess, but it would be far more trivial to make this work with an APL or a Lisp/Scheme. There already is great research for APL[0] and looking at the syntax of HVM-core it seems it is rather easy to knock up a CL DSL. If only there were more hours in a day.
[0] https://github.com/Co-dfns/Co-dfns