3 ms·

This guy really misses the point. You don't put 1024 x86 cores on a chip because the programming model of individual threads being scheduled ad-hoc doesn't scal

This guy really misses the point. You don't put 1024 x86 cores on a chip because the programming model of individual threads being scheduled ad-hoc doesn't scale that well (and imposes a lot of overhead on the control apparatus). But on a GPU, it is typical to have well over 1000 cores using a different programming model that accounts for memory access and grouping threads together to accomplish shared work and shared memory accesses. So, the same work is now being done with slightly different algorithms that exploit this programming model.

zozbot234 7y ago
CUDA/SPIR-V "cores" are not true cores - they're the equivalent of CPU execution units (ALU's). You don't really "group threads together" on a GPU, so much as use a single real "thread" to execute a whole bunch of computations in lockstep, using a lightly-extended SIMD model. That's the only way you can make such a huge amount of execution units/ALU's useful, and not all domains are well-suited to this approach. (Which is one reason why a lot of code still runs on plain multicore CPU's.)
- sdenton4 7y ago
  Yah, though I think there is more to be gained than often realized. Many algorithms can be rewritten to run much faster on gpus, though it takes some effort (and a different perspective, as a designer and programmer). I rewrote a toeplitz matrix solver not so long ago; it was pretty fun! Treat conditional statements as plagues, and don't worry as much about early stopping... Every example takes the worst case time to handle, but you can do thousands of them at the same time. Ended up getting about a 1000x speed up against the baseline.
vardump 7y ago
I think it's you who missed the point. If your algorithm requires any serial coordination between execution units, you're hosed, whether you're using CPU, GPU or really anything that can be used for computation. There are a set of algorithms that are "embarrassingly parallel", and that's where for example many graphics tasks fall. Same is not true in general.

zozbot234 7y ago

CUDA/SPIR-V "cores" are not true cores - they're the equivalent of CPU execution units (ALU's). You don't really "group threads together" on a GPU, so much as use a single real "thread" to execute a whole bunch of computations in lockstep, using a lightly-extended SIMD model. That's the only way you can make such a huge amount of execution units/ALU's useful, and not all domains are well-suited to this approach. (Which is one reason why a lot of code still runs on plain multicore CPU's.)

sdenton4 7y ago
Yah, though I think there is more to be gained than often realized. Many algorithms can be rewritten to run much faster on gpus, though it takes some effort (and a different perspective, as a designer and programmer). I rewrote a toeplitz matrix solver not so long ago; it was pretty fun! Treat conditional statements as plagues, and don't worry as much about early stopping... Every example takes the worst case time to handle, but you can do thousands of them at the same time. Ended up getting about a 1000x speed up against the baseline.

vardump 7y ago

I think it's you who missed the point. If your algorithm requires any serial coordination between execution units, you're hosed, whether you're using CPU, GPU or really anything that can be used for computation. There are a set of algorithms that are "embarrassingly parallel", and that's where for example many graphics tasks fall. Same is not true in general.