4 ms·

Aren't GPUs a bit like your example but not quite as extreme? The CPU you describe would be great for embarrassingly parallel simulation, machine learning, and

by api 6y ago

Aren't GPUs a bit like your example but not quite as extreme? The CPU you describe would be great for embarrassingly parallel simulation, machine learning, and similar tasks. I wish there was such a thing. Another thought that I’ve had for a while is that Intel’s Itanium was maybe a good idea badly executed or before it’s time. If you really could offload a lot of that to the compiler you could in theory maintain a lot of single thread performance while having far more cores.

quelsolaar 6y ago
Yes, you are correct! GPUs are essentially, very many simpler cores on a big die, and the reason it works is that the programing model is inherently parallel. (You almost always want to compute many pixels) GPU "cores" are different because they have graphics specific instructions like texture lookups. They are also different because you want to run the exact same program on many cores at once. So you have have one instruction decoder/dispatcher that control more then one core. This leads to some weird behavior, like if you have a branch in shader code, all cores may compute both branches, but then each core may mask away the result of what ever branch the specific core shouldn't have taken.
- imtringued 6y ago
  That's a really weird explanation of SIMD. There are big fat cores in GPUs but each core can process the same instruction stream 32 or 64 times but with different data. If there is only one core but two branches have to be taken it is obvious that the core has to process one branch after the other. Your "there are cores inside my cores" explanation is what's causing the confusion.
- MaxBarraclough 6y ago
  > if you have a branch in shader code, all cores may compute both branches As imtringued suggests, that's not quite right. In SIMD terms, all lanes of the core will be 'along for the ride' in case of control-flow diverging. The core must run the instructions for both branches, effectively disabling and re-enabling its various lanes as necessary. When disabled, a lane does no work. What SIMD calls a lane, SIMT calls a work-item or (perhaps more confusingly) a thread. The term 'core' refers to the level at which there is independent control-flow, much like in CPUs. See https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads https://en.wikipedia.org/wiki/Single_instruction,_multiple_t...
seniorivn 6y ago
there is a microprocessor design that attemps to do just that https://en.wikipedia.org/wiki/MCST https://en.wikipedia.org/wiki/MCST it's a russian company, heavily backed by russian government/army/3letteragencies it's hard to tell how successful they are, but there are some benchmarks https://github.com/EntityFX/anybench/blob/master/results/e2k_compare.md https://github.com/EntityFX/anybench/blob/master/results/e2k...

by api 6y ago

quelsolaar 6y ago

Yes, you are correct! GPUs are essentially, very many simpler cores on a big die, and the reason it works is that the programing model is inherently parallel. (You almost always want to compute many pixels) GPU "cores" are different because they have graphics specific instructions like texture lookups. They are also different because you want to run the exact same program on many cores at once. So you have have one instruction decoder/dispatcher that control more then one core. This leads to some weird behavior, like if you have a branch in shader code, all cores may compute both branches, but then each core may mask away the result of what ever branch the specific core shouldn't have taken.

imtringued 6y ago
That's a really weird explanation of SIMD. There are big fat cores in GPUs but each core can process the same instruction stream 32 or 64 times but with different data. If there is only one core but two branches have to be taken it is obvious that the core has to process one branch after the other. Your "there are cores inside my cores" explanation is what's causing the confusion.
MaxBarraclough 6y ago
> if you have a branch in shader code, all cores may compute both branches As imtringued suggests, that's not quite right. In SIMD terms, all lanes of the core will be 'along for the ride' in case of control-flow diverging. The core must run the instructions for both branches, effectively disabling and re-enabling its various lanes as necessary. When disabled, a lane does no work. What SIMD calls a lane, SIMT calls a work-item or (perhaps more confusingly) a thread. The term 'core' refers to the level at which there is independent control-flow, much like in CPUs. See https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads https://en.wikipedia.org/wiki/Single_instruction,_multiple_t...

seniorivn 6y ago

there is a microprocessor design that attemps to do just that https://en.wikipedia.org/wiki/MCST https://en.wikipedia.org/wiki/MCST it's a russian company, heavily backed by russian government/army/3letteragencies it's hard to tell how successful they are, but there are some benchmarks https://github.com/EntityFX/anybench/blob/master/results/e2k_compare.md https://github.com/EntityFX/anybench/blob/master/results/e2k...