5 ms·
tmurray is basically right: most of the really big reported gains are artifacts of unoptimized CPU code. Except for hardware special functions on GPUs, you shou
by _ihaque 12y ago
tmurray is basically right: most of the really big reported gains are artifacts of unoptimized CPU code. Except for hardware special functions on GPUs, you shouldn't be able to exceed the theoretical perf ratios between GPU and CPU, which are roughly ~30x in FLOPs and ~10x in bandwidth. Depending on whether arithmetic or memory is the algorithmic bottleneck, you'll hit one of those limits.
I wrote a paper [1] on this in one particular domain (computational chemistry) more or less as a rebuttal to a paper that claimed enormous GPU speedups; it was a consequence of slow CPU code, not especially fast GPU code.
[1] http://cs.stanford.edu/people/ihaque/papers/2dtanimoto.pdf http://cs.stanford.edu/people/ihaque/papers/2dtanimoto.pdf
- sklogic 12y agoOne should not forget another important thing: 1GFLOP in CPU is more expensive in terms of power than 1GFLOP in a GPU. So it's not only about chasing GFLOPs, in the mobile and embedded world it's also all about power.
- brigade 12y agoBut normalizing for power reduces the GPU advantage even more! Haswell for instance achieves about 5.3-5.8 GFLOP/W, compared to 24-28 GFLOP/W of Maxwell. That's less than a 5x theoretical computational gain.
- sklogic 12y agoTake a look at, say, Raspberry Pi: 24GFLOP for 1/2W. You won't get this for any number of mobile CPU cores.
- tmurray 12y agobut that's GLES 2.0, which is significantly less flexible than the kinds of GPUs we're discussing here and is not even in the same ballpark as a CPU (and almost certainly significantly less strict in terms of floating point precision than a GLES 3 device).
- sklogic 12y agoYet, it's pretty sufficient for things like FFT.
- kragen 12y agohttps://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/hello_pi/hello_fft/qasm/gpu_fft_128k.qasm#L219 https://github.com/raspberrypi/userland/blob/master/host_app... is part of the Raspberry Pi GPU FFT example code. That is not GLES 2.0 or even GL of any kind. That's VideoCore QPU assembly language to compile with qasm. I haven't tried writing anything for it, but it certainly looks like it's "the kinds of GPUs we're discussing here" and "in the same ballpark as a CPU".
- brigade 12y agoMobile SoCs claimed numbers are hard to take at face value. For one, I'm 98% sure that's FP16 flops. For another, basically all SoCs in shipping devices throttle under load, so efficiency is hard to determine from unrelated peak performance and max power draw numbers. Anyway, Cortex-A15 is capable of 8 flops per cycle per core which puts it pretty good in theoretical efficiency for its likely power draw at current clocks.
- sklogic 12y agoNo, these are fair 32bit GFLOPs. No, VC4 do not throttle, power figures are given for the real max load. And I never managed to get close to 8 ins per cycle on A15, but, for example, an FFT implementation on VC4 is pretty close to a theoretical performance limit. And a fully loaded 4-core A15 will draw far above 500mW anyway.