I know, but to enable running complex code you need a substantial stack size, which means the thread count has to be minimal, which in turn can only be achieved with out-of-order execution.
Since LRB1 didn't achieve the peak performance and power efficiency to compete with GPUs, what makes you confident it can be implemented cheaply and efficiently? Still sounds like more convergence to me.
Like I said, all the advantages of OoO are already there.
There's lots of ff hw still there. The compute density of gpu's is higher than lrb1. The driver teams have much more experience than what lrb1 team had at the time. There's no x86 penalty.
Hell, even a $200 APU will trash such a monster.
We need sticky thread filled exclusively with links to awesome papers.
In each of these, the CPU reaches high utilization (except when limited by the lack of gather/scatter). Now imagine what that graph looks like with twice the cores (to match die size and power), four times the computing power per core, and gather/scatter.
The more general problem is actually what the scores tell about the code those computers will actually encounter in reality. It's almost nothing. Just solving huge systems of linear equations isn't what most of these systems do as their daily work.
The term superscalar was meant to describe the simultaneous issue to several scalar ALUs/pipelines. So while the SIMD extensions of CPUs blur the line a bit of course, a normal CPU is a superscalar CPU anyway (look at the Integer-core!), just with some shallow vector unit(s) attached to it, which may (intel) or may not (AMD) use the same scheduler. So they effectively unify both concepts, scalar and vector pipelines both allowing the simultaneous issue of instructions.
The fundamental thing is that "scalar" describes a value (and not an instruction!) representable by a single number, a vector is represented by several numbers. That's where the fundamental distinction between scalar processors and vector processors originated: does an instruction operate on scalars (single values as operands) or on vectors (operands are vectors)? The evolution to superscalar processors didn't change that fundamental difference, adding the simultaneous issue to scalar ALUs. Of course you can add the same to vector processors. But starting to call vector processors now superscalar because of their capability for simultaneous issue of instructions appears a bit ridiculous to me. Scalar vector units, seriously?
But that tells me, that nvidia's marketing works after all
supervector or supersimd makes sense but good luck getting people to use that! In any case, from a software standpoint GF104 is superscalar. Arguments over whether hardware configuration or software perspective is more important can now ensue
See, you are looking at the wrong thing again. ie, you must look at the contract points. Converting from a HLL to a LLL doesn't tell you anything about the software interface of a device.No they're not. Lots of workloads look something like this:
sequential code
repeat N times
{
independent iterations
}
sequential code
repeat M times
{
dependent iterations
}
...Larrabee has less fixed-function hardware, so its compute density should have been higher than that of a GPU, unless having a "flexible memory hierarchy" is to blame. I really don't think the x86 overhead is of any significance, since classic Pentium cores are tiny and other ISAs aren't free to implement either. I estimate the overhead is a low single digit percentage.
