Is contributing to Triton so bad? It looks like the blocker is usually LLVM.
Helion: A high-level DSL for performant and portable ML kernels
11–20 of 52 posts
Re: Helion: A high-level DSL for performant and portable ML kernels
#12I'm super excited to give this one a spin. It seems like a neat idea, Triton, but simpler and with automatic autotuning. My head is spinning with options right now. I love how everyone was hyping up CUDA this and CUDA that a couple of years ago, and now CUDA is all but irrelevant. There's now so many different and opinionated takes on how you should write high performant accelerator cluster code. I love it. It's also…
In what alternative reality is that the case?
Re: Helion: A high-level DSL for performant and portable ML kernels
#13I'm super excited to give this one a spin. It seems like a neat idea, Triton, but simpler and with automatic autotuning. My head is spinning with options right now. I love how everyone was hyping up CUDA this and CUDA that a couple of years ago, and now CUDA is all but irrelevant. There's now so many different and opinionated takes on how you should write high performant accelerator cluster code. I love it. It's also…
> and now CUDA is all but irrelevant. Lol this is so wrong it's cringe. > There's now so many different and opinionated takes on how you should write high performant accelerator cluster code. I love it. There are literally only 2: SIMT (ie the same as it always was) and tiles (ie Triton). That's it. Helion is just Triton with more auto-tuning (Triton already has auto-tuning).
Even for non-ML things like chem simulations: CUDA (and cuFFT) are more pleasant to use than Vulkan Compute and vkFFT.
Re: Helion: A high-level DSL for performant and portable ML kernels
#14Tangential question related to the example kernel: in GPU programming is it idiomatic/standard to initialize the out array as zeros rather than empty? are the performance savings negligible?
Re: Helion: A high-level DSL for performant and portable ML kernels
#15Earlier quoted context omitted.
> and now CUDA is all but irrelevant. Lol this is so wrong it's cringe. > There's now so many different and opinionated takes on how you should write high performant accelerator cluster code. I love it. There are literally only 2: SIMT (ie the same as it always was) and tiles (ie Triton). That's it. Helion is just Triton with more auto-tuning (Triton already has auto-tuning).
Even for non-ML things like chem simulations: CUDA (and cuFFT) are more pleasant to use than Vulkan Compute and vkFFT.
I just learned the graphics api of vulkan, can’t imagine anything being less pleasant than vulkan
Re: Helion: A high-level DSL for performant and portable ML kernels
#16The developers also gave a talk about Helion on GPU Mode:
https://www.youtube.com/watch?v=1zKvCLuvUYc
Re: Helion: A high-level DSL for performant and portable ML kernels
#17I dont get the point of helion as compared to its alternatives like gluon.
For best performance I would presume one needs low-level access to hardware knobs. And, these kernel primitives are written one-time and reused. So, what is the point of a DSL that dumbs things down as a wrapper around triton.
Re: Helion: A high-level DSL for performant and portable ML kernels
#18Anything as long as I don't have to touch propriety cuda and mpx
Re: Helion: A high-level DSL for performant and portable ML kernels
#19I dont get the point of helion as compared to its alternatives like gluon. For best performance I would presume one needs low-level access to hardware knobs. And, these kernel primitives are written one-time and reused. So, what is the point of a DSL that dumbs things down as a wrapper around triton.
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.
Re: Helion: A high-level DSL for performant and portable ML kernels
#20I posted this 5 days ago, how did this resurface?