W/r to GPUs, I prefer to consider the SMs and SMXs as "cores" rather than ALU units within an SM/SMX. With that definition, a single K20 SMX can issue up to 25

W/r to GPUs, I prefer to consider the SMs and SMXs as "cores" rather than ALU units within an SM/SMX. With that definition, a single K20 SMX can issue up to 256 instructions per cycle (4 dual-issues of instructions across 4 32-way warps) and they each carry effectively 368K of L1 cache (64K true L1 plus an enormous 256K register file plus 48K of read-only cache). Speaking from experience, ~40 warps are needed to saturate the instruction pipeline. The 1.25 MB L2 is shared among the 15 SMXs. 208 GB/s of main memory bandwidth is shared between the 15 SMXs providing each one with ~14 GB/s. Each Xeon Phi core has a 32K L1 data cache and a 512K L2 data cache. A Xeon Phi core can issue 16 SIMD operations/cycle and it needs 4 threads to saturate the instruction pipeline. The 60 cores in a 5110P have to share 320 GB/s of main memory bandwidth or 5.33 GB/s per core. And all of this means that code customized for one processor (OpenCL) will run like crap on the other one. The Xeon Phi needs that 30 MB of total individual L2 cache to avoid slamming into memory bus contention while the K20 needs to operate entirely inside its L1 cache and register file to hit peak performance. Main memory fetches are less fatal to the K20 both because optimized code will be running 40+ warps to bury the latency and because of the significantly higher bandwidth. What strikes me at this point is absolutely paucity of compelling Xeon Phi benchmarks. All we see are SGEMM, DGEMM, and a bunch of synthetic tests. They've had 6 years to get this right so why didn't they go after all the jewels in NVIDIA's many-core crown from the get-go? Finally, languages like OpenCL and CUDA subsume SIMD, multithreading, multi-core, and cache optimization into the programming model, all but implicitly forcing the programmer into optimizing many-core performance. In contrast, Intel continues to expect programmers to use processor-specific intrinsics to hit peak performance that change with vendor and processor generation. Sure, it's easier to write serial code for a serial Intel core. But I thorughly disagree that it's easier to write many-core applications by adding processor intrinsics and a threading library to fundamentally serial code.