Helion abstracts syntax and design for calculating λ-functions, which converts language in a kernel config.
Helion: A high-level DSL for performant and portable ML kernels
31–40 of 52 posts
Re: Helion: A high-level DSL for performant and portable ML kernels
#32Earlier quoted context omitted.
I just learned the graphics api of vulkan, can’t imagine anything being less pleasant than vulkan
Yeah it's quite something. If anyone wants a preview, here's the triangle hello world in vulkan: https://gist.github.com/Overv/7ac07356037592a121225172d7d78f... But then again, I've heard that it's this low level because its meant for engine developers.
Re: Helion: A high-level DSL for performant and portable ML kernels
#33Earlier quoted context omitted.
Funny, I feel the same way about Triton. Performant Triton looks like CUDA (but with tiles!) except it's ten times harder to debug since it doesn't have the tooling NVIDIA provides. If I had to run on AMD I'd rather deal with their hipify tooling.
Performant Triton programs are usually simpler and shorter than their CUDA equivalents. This alone makes it easier to write, and I would argue that it helps with debugging too because the model provides a lot more guarantees on how your code executes. That said, some of the tooling is notably poor (such as cuda-gdb support).
Getting rid of the for loop over an array index doesn't make it easier to understand the hard parts. Losing the developer perf and debug tooling is absolutely not worth the tradeoff.
For me I'd rather deal with Jax or Numba, and if that still wasn't enough, I would jump straight to CUDA.
It's possible I'm an old fogey with bias, though. It's true that I've spent a lot more time with CUDA than with the new DSLs on the block.
Re: Helion: A high-level DSL for performant and portable ML kernels
#34Asking as someone who is really out of the loop: how much of ML development these days touches these “lower level” parts of the stack? I’d expect that by now most of the work would be high level, and the infra would be mostly commoditized.
It's just like game optimization, cache-friendliness and memory hierarchy-awareness are huge in attention mechanism. But programming backward pass in these lower-level stacks is definitely not fun, tensor calculus breaks my brain.
Re: Helion: A high-level DSL for performant and portable ML kernels
#35Is it normal to spend 10minutes on tuning nowadays? Do we need to spend another 10 minutes upon changing the code?
Re: Helion: A high-level DSL for performant and portable ML kernels
#36Earlier quoted context omitted.
I just learned the graphics api of vulkan, can’t imagine anything being less pleasant than vulkan
Yeah it's quite something. If anyone wants a preview, here's the triangle hello world in vulkan: https://gist.github.com/Overv/7ac07356037592a121225172d7d78f... But then again, I've heard that it's this low level because its meant for engine developers.
Re: Helion: A high-level DSL for performant and portable ML kernels
#37Earlier quoted context omitted.
Yeah it's quite something. If anyone wants a preview, here's the triangle hello world in vulkan: https://gist.github.com/Overv/7ac07356037592a121225172d7d78f... But then again, I've heard that it's this low level because its meant for engine developers.
Really? How low is this level actually? Because I remember my OpenGL class' professor did this in less than 50 lines.
Re: Helion: A high-level DSL for performant and portable ML kernels
#38Earlier quoted context omitted.
Performant Triton programs are usually simpler and shorter than their CUDA equivalents. This alone makes it easier to write, and I would argue that it helps with debugging too because the model provides a lot more guarantees on how your code executes. That said, some of the tooling is notably poor (such as cuda-gdb support).
Agree on shorter, disagree on simpler. The hard part of understanding GPU code is knowing the reasons why algorithms are the way they are. For example, why we do a split-k decomposition when doing a matrix multiplication, or why are we loading this particular data into shared memory at this particular time, with some overlapping subset into registers. Getting rid of the for loop over an array index doesn't make it ea…
Re: Helion: A high-level DSL for performant and portable ML kernels
#39Re: Helion: A high-level DSL for performant and portable ML kernels
#40Is it normal to spend 10minutes on tuning nowadays? Do we need to spend another 10 minutes upon changing the code?
You mean autotune? I think 10 minutes is pretty normal, torch.compile('max-autotune') can be much slower than that for large models.