Starglider wrote:It isn't just 'issues with compilers'. With the amount of money and talent Intel threw at the problem, if it was just an 'issue' it would've been fixed long ago. On many problems it is intrinsically impossible to accurately predict at compile time exactly what the data mix and code path usage is going to look like, at least without a great deal of extra metadata from the programmer (which few programmers would know how to give and getting it wrong would be considerably worse than useless). For non-scientific applications the task is greatly complicated by the ever more pervasive use of dynamically linked and just-in-time compiled code.
Yes, I know. I was glossing over things considerably - as I mentioned, these all boil down to compiler issues in the end
It's pretty clear. For the same transistor budget you can have 4 conventional cores or 80 stripped down in-order stream-optimised cores. GPUs utterly blow away conventional processors for highly parallelisable highly predictable computation, this is why GP-GPU is so exciting. However, the bus is a bottleneck (in bandwidth and latency). Heterogeneous cores allow you to have serious highly parallel stream computation working in close synchrony with highly serial control code. The advantage is an order of magnitude more computing power on tasks that parallelise. The tools to do this easily are hard to write, but nowhere near as hard as EPIC compilers, because they don't have to be telepathic.
Yeah, for what you're doing that might be useful (as well as for many scientific computing roles) but that vast majority of tasks don't lend themselves to this sort of heterogeneous processor. They'd be better served by a homogeneous design. I think you're mirror-imaging your requirements and needs on the general computing industry.
