3 ms·
These days CPU vs GPU isn't about the number of ALUs or cores, it's about the latency hiding strategy. A GPU assumes oodles of similar threads are running at th
by smallmancontrov 3y ago
These days CPU vs GPU isn't about the number of ALUs or cores, it's about the latency hiding strategy. A GPU assumes oodles of similar threads are running at the same time, so the moment one blocks on a memory access another can be rotated in. It's hyper-hyper-hyper-hyper-...-hyper threaded. Meanwhile, a CPU is just hyper-threaded, if that, and instead it tries to be clever about prefetching, speculative execution, and the like.
So long as some important applications have tons of similar threads and some have very few threads, it will probably make sense to specialize.
- pixelpoet 3y agoYep, I see it as latency vs throughput optimisation, particularly wrt memory subsystem. What I was pointing out is, x86 is not well suited to GPU execution; Intel tried that with Larrabee. Moreover, in the latest generation Nvidia chips you have 72-96mb L2 cache and 2.5ghz+ clock speed, so it's remarkably capable per-thread. At some point, and I think 256 cores might be the ballpark, you're committing to using so many threads that you're probably mostly interested in high throughput. (I'm writing commercial path tracers so my bias is obvious!)
- adgjlsfhk1 3y agoone thing with high that cpus is you can use them to claw back against OS latency. you can do things like pin 128 cores for your application, 64 for your networking, 32 for disk IO and 32 general purpose, and keep the OS from scheduling other programs on the critical cores for running your program.