7 ms·
Not OP but I think this could be an instance of leaky abstraction at work. Most of the time you hand-write an accelerator kernel hoping to optimize for runtime
by smilekzs 1y ago
Not OP but I think this could be an instance of leaky abstraction at work. Most of the time you hand-write an accelerator kernel hoping to optimize for runtime performance. If the abstraction/compiler does not fully insulate you from micro-architectural details affecting performance in non-trivial ways (e.g. memory bank conflict as mentioned in the article) then you end up still having per-vendor implementations, or compile-time if-else blocks all over the place. This is less than ideal, but still arguably better than working with separate vendor APIs, or worse, completely separate toolchains.
- whimsicalism 1y agoYes, it looks like they have some sort of metaprogramming setup (nicer than C++) for doing this: https://www.modular.com/mojo https://www.modular.com/mojo
- totalperspectiv 1y agoI can confirm, it’s quite nice.
- whimsicalism 1y agojw: why do you use mojo here over triton or the new pythonic cute/cutlass?
- totalperspectiv 1y agoBecause I was originally writing some very CPU intensive SIMD stuff, which Mojo is also fantastic for. Once I got that working and running nicely I decided to try getting the same algo running on GPU since, at the time, they had just open sourced the GPU parts of the stdlib. It was really easy to get going with. I have not used Triton/Cute/Cutlass though, so I can't compare against anything other than Cuda really.