Larrabee delayed to 2011 ?

For tapping into the potential FLOPS of a current CPU you still need to write specific SIMD (ie SSE) code.
You would not want to do this with assembler but with intrinsics, which are very close to assembler;
just abstracting registers, still allowing normal C++ variables, flow control etc.

 

Would you prefer to write shader-like code (which is implicitly parallelized) or to write your kernels via intrinsics (and have full control..)?

 

With shared memory and guaranteed execution domains (ie. CUDA) the difference is rather arbitrary.

 

Correct. On top of my head, I can't think of any assembly language code in our codebase. If there exist any, it's not significant. However, there is some use of compiler intrinsics that are architecture specific, such as for SSE and Altivec. These are used in performance critical parts of the code.

Writing SSE code using intrinsics is generally orders of magnitude less productive than writing shader code, even if you have to spend time optimizing the high level code to generate better machine code (something you amy need to do on intrinsics code too btw). Anyone intending to write any significant portions of code for Larrabee using the intrinsics would be insane. The x86 ISA has no particular advantage I can see as a developer. Especially since it's not even the same x86. Larrabee is best programmed using OpenCL or HLSL.

 

Not totally true... the abstraction penalties with respect to work group sync and control flow are pretty hurtful in some cases. Put another way, there are operations that are cheap in hardware that are not (yet?) efficiently expressed in the DC/OpenCL/CUDA abstraction. That's not to say that the abstractions are not useful, but they're not totally "there" yet either.

 

Could you give examples about the kinds of code where SSE is useful in a game? CPU-based physics definitely qualifies. Sound processing maybe? But that about as far as my imagination takes me...

I suspect those intrinsics are very similar to those that are used to program TI DSP's in something that tries to pretends it's still C.

 

For programming GPUs, shader code definitely is the way. It still can pay off to look at the generated assembler to see if it's optimal and rearrange expressions accordingly.

 

Why wouldn't use the same strategy on a CPU or on a LRB-like architecture? In the end writing shaders is way easier and the programming model is likely to allow you to get very good performance with minimal effort, at least with fairly regular kernels/data.

 

They are very close to the assemblies, but you don't have to worry about register allocation or even scheduling. For example, it's like

Code:

__m128 a, b, c;
...
a = _mm_add_ps(b, c);

Basically _mm_add_ps directly map to the instruction ADDPS. Most intrinsics work this way. Although there are also a few intrinsics that's "combo," such as _mm_load1_ps (which loads from a single float and spread into the 4 words in a variable). There is no such instruction, so it's done with a load and a shuffle instruction.

Intel has tried to provide an overloaded C++ library with a 4D vector type which operators are overloaded to support SSE, so you just write a = b + c and it should be replaced with _mm_add_ps. This is in theory more readable but practically computation operators in C++ is not very much so it's not that useful.

There are also automatic vectorization compilers (I believe both Intel C++ compiler and GCC now have these options), but they are still not very good.

 

If you write code that needs to run on a CPU you can not use shader language.
With OpenCL for CPUs that may change.

 

That was my point. Just because you cannot do it right now it doesn't mean you won't be able to do it in the future (Cuda, OpenCL, etc..)

See http://www.cercs.gatech.edu/tech-reports/tr2009/git-cercs-09-01.pdf

 

Not really, much of it seems (to me) to be straight out of 1999.

 

It is used extensively in the occlusion culling code. Some use in terrain code as well, and some in the DX10 backend.

 

The unfavorable performance per area and power consumption of what Intel considers the most basic of x86 designs, the Atom core, compared to natively mobile cores like an ARM makes me inclined to believe that x86 overhead would become a design limit of any type of processor focused on being lean, like a GPU, and that it was a significant factor in Larrabee's failure.

 

We have argued here before that making the cores x86 was a bad decission in this case. I did not however though that it would delay/fail the project at all and we probably won't know for sure.

 

I personally thought LRBni was the first decent vector set in the history of Intel. After the back to back failures of MMX and SSE, I really lost faith Intel will be able to produce a decent vector set (we're up to SSE 4.2 and it's still being tinkered with and still lacking).
I didn't think the x86 "overhead" was such a big deal - after all they at least picked the IMHO last decent straight-up x86 implementation (Pentium1, pre-MMX). The ISA is certainly archaic but at least they were getting some value out of it, short pipeline, memory-ops, flexible address generation, etc.

 

Compared to TRIPS even that is rather traditional ... but it's revolutionary for Intel.

 

AMD says of Larrabee: "GPUs are hard to design and you can’t design one with a CPU-centric approach that utilizes existing x86 cores."