3 ms·

Aside from the other comments which provide great answers about the way GPUs work and their history... I want to give my gut instinct for why an API like this d

Aside from the other comments which provide great answers about the way GPUs work and their history... I want to give my gut instinct for why an API like this doesn't exist on top of all that history. I suspect it's simply because the "complexity floor" for running code on a GPU is already high. Obviously your trivial example is only for the sake of example. But I suspect that nobody has had the incentive to create an API that looks like that because anything close to that is just better done on the CPU. Once you have problems that need a GPU to solve, then working through the peculiarities of the complex API is worth it. I don't know this for a fact, but it's me reasoning backwards from the fact that nobody has seen fit to create an API like this, when all sorts of zany APIs exist. For example, there are already plenty of code generators for graphics-oriented shader programs, which will take e.g. a material description like `{color: red, opacity: 0.5, reflective: true}` and generate the GLSL code. Why would there not be an equivalent which compiles an expression language to GPGPU instructions? I must assume it's because the programs you might want to express with it are probably best run on the CPU.

kypro 4y ago
My example wasn't great, and you're right that this would be better ran on a CPU. For context, my very naive working model of GPUs is that they're basically just massively parallel CPUs with slower clock speeds. So given this it seems like it would make sense to have some kind of async math library which allow you to send batch calculations to the GPU to run in parallel. Basically anything where you typically create a loop and do some calculation seems like it would better batched and sent to the GPU. Assuming my working model of GPUs is correct anyway. So last week I was working on a JS library which required doing exactly this – some basic addition and multiplication in a loop – and I thought, hey, I wonder if I can just batch this and send it to the GPU for a slight performance boost? I was aware of projects like GPU.js and figured it should be a relatively simple thing to try, but turns out I was wrong. What I thought would take me 30 mins last week has now turned into a quest to learn about shader code and the history of GPUs, and I'm still not exactly sure why.
- Chabsff 4y ago
  "basically just massively parallel CPUs" is correct-ish, but it has the added wrinkle that you have to think of them as CPUs where large chunks of cores have to be executing the same instruction at the same time, which means that it's mostly loops where each iteration runs close to the same instructions that make sense. Also, I think you might be drastically underestimating how utterly insane modern JavaScript engines like V8 are. JS code running as well as it does on CPUs is sort of a minor miracle in the first place. Even then, there's still a place/need for WebASM on top of it. Transposing that unto a GPU in a transparent manner is asking a LOT. Not to mention that there's a lot of stuff you can do in JS that, if feasible at all, makes no sense whatsoever in GPU-land. Even basic stuff, e.g. string-based property lookups, just does not belong in GPU code for the most part. If I see an API that looks like `GPU.exec(Callable)`, then I expect that any callable can be passed to that API. In JavaScript, that can mean a LOT of different things, many of which would be hell on earth to convert to GPU-compatible code.
- kristjansson 4y ago
  Very, very wide SIMD units is also a good model. Your performance is proportional to how much of the same thing you're doing at once
- crabmusket 4y ago
  TIL about GPU.js, which on the face of it seems like exactly what you were asking for in your original comment. Was the problem that the code you wanted to write didn't quite fit into the expected execution model, even if GPU.js allowed you to write things in an ergonomic way?

kypro 4y ago

My example wasn't great, and you're right that this would be better ran on a CPU. For context, my very naive working model of GPUs is that they're basically just massively parallel CPUs with slower clock speeds. So given this it seems like it would make sense to have some kind of async math library which allow you to send batch calculations to the GPU to run in parallel. Basically anything where you typically create a loop and do some calculation seems like it would better batched and sent to the GPU. Assuming my working model of GPUs is correct anyway. So last week I was working on a JS library which required doing exactly this – some basic addition and multiplication in a loop – and I thought, hey, I wonder if I can just batch this and send it to the GPU for a slight performance boost? I was aware of projects like GPU.js and figured it should be a relatively simple thing to try, but turns out I was wrong. What I thought would take me 30 mins last week has now turned into a quest to learn about shader code and the history of GPUs, and I'm still not exactly sure why.

Chabsff 4y ago
"basically just massively parallel CPUs" is correct-ish, but it has the added wrinkle that you have to think of them as CPUs where large chunks of cores have to be executing the same instruction at the same time, which means that it's mostly loops where each iteration runs close to the same instructions that make sense. Also, I think you might be drastically underestimating how utterly insane modern JavaScript engines like V8 are. JS code running as well as it does on CPUs is sort of a minor miracle in the first place. Even then, there's still a place/need for WebASM on top of it. Transposing that unto a GPU in a transparent manner is asking a LOT. Not to mention that there's a lot of stuff you can do in JS that, if feasible at all, makes no sense whatsoever in GPU-land. Even basic stuff, e.g. string-based property lookups, just does not belong in GPU code for the most part. If I see an API that looks like `GPU.exec(Callable)`, then I expect that any callable can be passed to that API. In JavaScript, that can mean a LOT of different things, many of which would be hell on earth to convert to GPU-compatible code.
kristjansson 4y ago
Very, very wide SIMD units is also a good model. Your performance is proportional to how much of the same thing you're doing at once
crabmusket 4y ago
TIL about GPU.js, which on the face of it seems like exactly what you were asking for in your original comment. Was the problem that the code you wanted to write didn't quite fit into the expected execution model, even if GPU.js allowed you to write things in an ergonomic way?