HVM updates: simplifications, finally runs on GPUs, 80x speedup on RTX 4090 | Hacker News Reader

HVM updates: simplifications, finally runs on GPUs, 80x speedup on RTX 4090

twitter.com

91 pointsLightMachine29 comments

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.

https://nitter.net/VictorTaelin/status/1710766199288570079

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.

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.

100% agree - we're working on exactly that for the upcoming release in a few months!

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).

Wait, so "by compiling languages like Python, Haskell, to a new format called Interaction Net" actually means the compiler hasn't been written yet?

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).

This might be a dumb question, but is it possible to take something like WASM and make it run on HVM?

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 :)

I don't know, does Erlang elaborate to a simple core language?

Yes! https://www.erlang.org/blog/core-erlang-by-example/

Both elixir and erlang (and all Beam languages elaborate to Core Erlang)

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.

[0] https://github.com/Co-dfns/Co-dfns

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!

Someone did run Linux in a pixel shader on VRChat.

https://blog.pimaker.at/texts/rvc1/

do erlang! (or elixir!) instead of python :)

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.

We're providing support to all GPUs soon, NVidia is only the first target because it provides the most convenient language (CUDA).

Your analogy would be valid only if there were three car manufacturers and one of them basically had 60%+ market share. It's not the same.

80% of discrete desktop GPUs, 90% of “datacenter”.

Reply on news.ycombinator.com