[HN Gopher] Next-Gen GPU Programming: Hands-On with Mojo and Max...
___________________________________________________________________
Next-Gen GPU Programming: Hands-On with Mojo and Max Modular HQ
Author : solarmist
Score : 35 points
Date : 2025-04-25 18:32 UTC (4 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| solarmist wrote:
| I'm really hoping Modular.ai takes off. GPU programming seems
| like a nightmare, I'm not surprised they felt the need to build
| an entire new language to tackle that bog.
| mirsadm wrote:
| GPU programming isn't really that bad. I am a bit skeptical
| this is the way to solve it. The issue is that details do
| matter when you're writing stuff on the GPU. How much shared
| memory are you using? How is it scheduled? Is it better to
| inline or run multiple passes etc. Halide is the closest I
| think.
| solarmist wrote:
| What are you skeptical of? I believe the problem this is
| solving is a framework that's not CUDA that allows low level
| access to the hardware, makes it easy to write kernels, and
| is not Nvidia only. If you watch the video you can write
| directly in asm if you need to. You have full control if you
| want it. But it provides primitives and higher level objects
| that handle common cases.
|
| I'm a novice in the area, but Chris is well respected in this
| area and cares a lot of about performance.
| pjmlp wrote:
| There are already plenty of languages in CUDA world, that is
| one reasons it is favoured.
|
| The problem isn't the language, rather how to design the data
| structures and algorithms for GPUs.
| solarmist wrote:
| Not sure I fully understand your comment, but I'm pretty sure
| the talk addresses exactly that.
|
| The primitives and pre-coded kernels provided by CUDA (it
| solves for the most common scenarios first and foremost) is
| what's holding things back and in order to get those
| algorithms and data structures down to the hardware level you
| need something flexible that can talk directly to the
| hardware.
| pjmlp wrote:
| C, C++, Fortran, Python JIT from NVidia, plus Haskell,
| .NET, Java, Futuhark, Julia from third parties, and
| anything else that can bother to create a backend targeting
| PTX, NVVM IR, or now cuTile.
|
| The pre-coded kernels help a lot, but you don't have to use
| them necessarly.
| diabllicseagull wrote:
| It is a noble cause. I've spent ten years of my life using CUDA
| professionally, outside the AI domain mind you. Most of these
| years, there was a strong desire to break off of CUDA and the
| associated Nvidia tax on our customers. But one thing we didn't
| want was to move from depending on CUDA to depending on another
| intermediary which would also mean financial drain, like the
| enterprise licensing these folks want to use. Sadly, open source
| alternatives weren't fostering much confidence, either with their
| limited feature coverage or just not knowing if they will be
| supported in the long term (support for new hardware, fixes,
| etc.).
| catapart wrote:
| My mistake completely, but I thought this was going to be
| something to do with a new scheme or re-thinking of graphics
| programming APIs, like Metal, Vulkan or OpenGL. Now I'm kind of
| bummed that it is what it is, because I got really excited for it
| to be that other thing. =(
| pjmlp wrote:
| That is already taking place with work graphs, and making
| shader languages more C++ like.
| ttoinou wrote:
| Seems like with it you will be able to compile and execute one
| code on multiple GPU targets though
| ashvardanian wrote:
| There is a "hush-hush open secret" between minutes 31 and 33 of
| the video :)
| refulgentis wrote:
| TL;Dr same binary runs on Nvidia and ATI today, but not
| announced yet
| throwaway314155 wrote:
| They desperately need to disable whatever noise cancellation
| they're using on the audio. Keeps cutting out, sounds terrible.
| solarmist wrote:
| Yeah, the mic quality was terrible.
___________________________________________________________________
(page generated 2025-04-25 23:01 UTC)