Derfnofred
Gawd
- Joined
- Dec 11, 2009
- Messages
- 606
GPU's are in no way "orders of magnitudes more efficient" at FP math than CPUs, they just have orders of magnitudes more cores.
TL;DR: The design of the FPU in a GPU vs CPU are two entirely different beasts, CPU needs small number of problems solved in a short time, GPU needs a large number of problems solved independent of each other but less time constraint on each individual problem.
Agree with almost all your post except the first part (and only when framed in a different light than perhaps the direction you're taking it), in that FLOPS/watt, one very useful form of efficiency, is generally higher on a GPGPU than a CPU due to the simplified architecture, seeing as they're designed expressly around SIMD. Likewise, you could say something like flops/cm^2 of die area is favorable to GPGPU for the same reason--it's far less flexible in hardware.
Amdahl's Law strikes again when you look at computational needs of a consumer-centric processor: floating point operations tend to either be sequential in nature, or media/graphically-based and massively parallel, which is where we already sit (by and large). Places where we'd likely see the greatest accelerations in software performance from a bunch of slightly-more-flexible-yet-still-massively-parallel FPU's would be in content creation software (think Adobe's suites), spreadsheet/database applications. But your scheduler and/or compilers are going to get a LOT more complex to do it.
A poster mentioned we're more likely to see more SIMD optimizations in our CPUs than GP optimizations in our GPUs--I agree, and even more so, we might start seeing more big.LITTLE type solutions if the schedulers can handle it efficiently.