3 ms·

When you've got a huge out of order engine the extra effort it takes to decode x86 instructions is lost in the noise. When you're going with the flock of chick

When you've got a huge out of order engine the extra effort it takes to decode x86 instructions is lost in the noise. When you're going with the flock of chickens approach and you have a huge number of very small cores then the overhead is killer. Intel tried to solve this by using medium cores with big SIMD units but SIMD is just less flexible than a GPU's SIMT is. Power and area generally scale as the square of the single threaded performance of a core. The huge number of "cores"/lanes in a GPU are much smaller and more efficient individually than even your phone's smaller cores. And the x86 tax gets worse and worse the smaller you try to make a core with the same ISA. Intel wasn't even able to succeed in competing with the Atom against medium sized cellphone chips.

rbanffy 9y ago
> but SIMD is just less flexible than a GPU's SIMT is There is nothing preventing the x86 ISA to be extended in that direction. As long as all cores (oxen and chickens, as Seymour Cray would say) can shift binaries around according to desired performance/power, I don't care. Binary compatibility is awesome for software that has already been written and for which we don't have the source code. Pretty much everything on my machines has source available. The OS may need to be more aware of performance characteristics of software it's running on the slightly different cores so it can be better allocated, but, apart from that, it's a more or less solved problem. Atoms didn't perform that much worse than ARMs on phones. What killed them is that they didn't run our desktop software all that well (even though one of my favorite laptops was an Atom netbook).