3 ms·
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.
by ColonelPhantom 3y ago
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)?
- LightMachine 3y agoGood 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.
- aeonik 3y agoKeep 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.