Larabee x86 compatible or not?

[magreen]

(Please excuse the forum choice. I know Larabee is a gpu and nvidia is a gpu maker. But this is an x86 question and I think the talented and knowlegeable guys on the cpu forum would be the best to answer this.)

Source:
http://www.anandtech.com/trade...howdoc.aspx?i=3391&p=2

"NVIDIA pointed out that Larrabee x86 isn't binary compatible with other Intel x86 processors (since it doesn't support any of the SSEs) - so there's no advantage there. Honestly, x86 today is a burden for Larrabee, not a boon as it is not the most desirable ISA from anything other than a compatibility standpoint. The difference between G2xx and Larrabee is in the programming model not the ISA. It's the threading model with G2xx that the developer complaints are really about."

Please discuss. Is nvidia right that Larabee's x86 support is just talk with no tangible benefit?

 

[lambchops511]

Pentium II does not have SSE . is it x86 compatible?

 

[Idontcare]

Originally posted by: aznium
Pentium II does not have SSE . is it x86 compatible?

Exactly.

SSE is intended to speed-up certain instructions. Being SSE compatible (software app-wise) does not mean the software is x86 incompatible, just means it has been coded to take advantage of the speedups that SSE instructions offer.

Now I suppose there is nothing preventing software engineers from creating code that is strictly dependent on a specific SSE instruction such that when attempted to run on an earlier CPU (such as P2) or a newer CPU w/o SSE then it would crash or refuse to run.

But that means the software itself is not x86 compatible, not the hardware.

 

[magreen]

So it actually is binary compatible, despite what Jen Hsun said (and Anand seemed to tacitly agree with) ?

 

[Idontcare]

Originally posted by: magreen
So it actually is binary compatible, despite what Jen Hsun said (and Anand seemed to tacitly agree with) ?

It depends on who said it was x86. If Intel actually described it as an x86 processor then yes it must be binary compatible. If someone else is skewing the words and deciding to call it x86 then that is whole other thing.

To recollection the Larrabee IDF presentation did explicitely state Larrabee was x86, but I'm not looking at it right now so I am going by memory.

There is a catch here, of course, and that is that Larrabee can be x86 all it wants. Hell it could be a repacked Nehalem for all we care, but that still doesn't mean we (you and me and the other consumers) are going to have any access to the processing capability on Larrabee unless Intel decides to make it openly available in some form of "CUDA" type access.

Sure new programs could be written for Larrabee just as F@H was done for the GPU's. But I don't forsee Vista SP1 migrating your Photoshop CS3 threads from your Nehalem CPU over to your Larrabee GPU and back again. It would be sweet, don't get me wrong I'd kill for a hybrid computing platform like that, but I don't see it being implemented in such a way that helps existing software at all (just as new SSE instructions don't help speedup existing software apps).

 

[magreen]

Interesting... I thought I read that one of the draws of Larabee was you might see your Larabee "cores" show up in your OS's task manager along with your cpu cores. And then the OS and/or app could pick which (type of) core to run a thread on. But hey, maybe that's just dreamin'.

 

[CTho9305]

I would argue that even if Larrabee is x86 compatible, you don't gain much from the compatibility. You can't take advantage of the wide SIMD pipes if you don't recompile to the new instructions for the "coprocessors"... you just get an array of horrible-IPC in-order x86 processors with very low performance-per-die-area (since each one has a big idle vector unit sitting next to it) and questionable (based on what I've seen so far) performance-per-watt.

 

[Foxery]

Originally posted by: CTho9305
I would argue that even if Larrabee is x86 compatible, you don't gain much from the compatibility. You can't take advantage of the wide SIMD pipes if you don't recompile to the new instructions for the "coprocessors"... you just get an array of horrible-IPC in-order x86 processors with very low performance-per-die-area (since each one has a big idle vector unit sitting next to it) and questionable (based on what I've seen so far) performance-per-watt.

The pitch from Intel is that it's x86 for ease of programming. Coders can write everything in good ol' C instead of needing to learn the ins and outs of CAL/Brook (ATi), and CUDA (nVidia), and coping with the constant changes these could potentially go through. Current GPUs are also not able to run all x86 instructions, and have precision limitations for others. i.e. "Love us for using an old tried & true standard, instead of inventing new ones."

 

[aigomorla]

wow nvidia is really trying hard to piss off intel huh?

 

[XBoxLPU]

http://www.anandtech.com/cpuch...howdoc.aspx?i=3367&p=8

 

[magreen]

Originally posted by: aigomorla
wow nvidia is really trying hard to piss off intel huh?

Well, they are going to open up a can of whoop-ass, after all.

 

[Idontcare]

Originally posted by: magreen

Originally posted by: aigomorla
wow nvidia is really trying hard to piss off intel huh?

Well, they are going to open up a can of whoop-ass, after all.

Yeah but they weren't supposed to drink it too! Your suppose to serve a can of whoop-ass after you open it up, not drink it down yourself. That's sooo AMD.

 

[Fox5]

Originally posted by: magreen
So it actually is binary compatible, despite what Jen Hsun said (and Anand seemed to tacitly agree with) ?

Many programs nowadays assume at least SSE, some SSE2.

Also, x86-64 requires SSE2.

 

[taltamir]

when was the last time you saw a program compatible with a pentium 2 and below?

Almost every program I know requires at least SSE2... some rare ones require SSE3 and SSE4...

It gets the drawback of x86 (a part of it needs to be a decoder) without the benefits (SSE support).

Bottom line, programs would have to be specifically programmed for it, just like with CUDA. Actually, I think it will take more effort to do so then with CUDA.
Its a stripped down (in order, etc; causes loss of performace), shrunk (lower nm process), and much faster clocked pentium one chip array. Very limited in use.

 

[Foxery]

Originally posted by: taltamir
Almost every program I know requires at least SSE2... some rare ones require SSE3 and SSE4...

Bottom line, programs would have to be specifically programmed for it, just like with CUDA. Actually, I think it will take more effort to do so then with CUDA.

Negative. The compiler can recreate binaries for any specified set of added instructions, or none at all. SSE is a bonus, not a requirement, to run from the original C code. No new programming is necessary.

 

[taltamir]

people program at least C++, which is C code with many precompiled libraries...
If you could just "recompile anything in C code" then all programs could run on nvidia cards thanks to cuda.

 

[Cogman]

Originally posted by: taltamir
people program at least C++, which is C code with many precompiled libraries...
If you could just "recompile anything in C code" then all programs could run on nvidia cards thanks to cuda.

uhhhh. no. no no no no... C++ is not just C with precompiled libraries.... Wow, just no. You might as well say C# is just Microsoft's spin on C++ and that lisp is really just C with a different syntax.

C++ is a different language then C. most C code can be compiled with a C++ compiler, but most C code can not be compiled by a C compiler.

Programs can be recompiled with CUDA. the problem is that it has a really contrived threading model that makes the performance benefit moot. If you application doesn't conform to the Cuda threading model then you will see no benefit to running it on the graphics card (it will even be a fair amount slower).

The only place where a single threaded app would see a good speed increase is where the application does tons of floating point calculations. (Folding@home)

 

[Cogman]

Originally posted by: Fox5

Originally posted by: magreen
So it actually is binary compatible, despite what Jen Hsun said (and Anand seemed to tacitly agree with) ?

Many programs nowadays assume at least SSE, some SSE2.

Also, x86-64 requires SSE2.

No, x86-64 does not require SSE2. SSE2 is included because it adds a fairly good performance increase across a large board of applications. MMX, 3dNow. ect are all not required by any x86 standard, but added features for faster processing.

 

[taltamir]

oh, and 64bit recompile as well. we'd see more of that...
As for "it will work, just underperform"... what makes you think the larabee x86 without any addiitons would be any different? It will also work but under perform. In which case it defeats the purpose.

C# has nothing to do with C or C++. C# is a runtime environment type of code, that is similar to java in syntax (and in requiring a runtime environment, and in introducing inefficiency to the code due to it), Easier to program in, but makes inefficient programs that can only run on machines with a .net environment, which is not supported anywhere but windows (countering the sole reason why such a model is tolerable with java).

 

[Cogman]

Originally posted by: taltamir
oh, and 64bit recompile as well. we'd see more of that...
As for "it will work, just underperform"... what makes you think the larabee x86 without any addiitons would be any different? It will also work but under perform. In which case it defeats the purpose.

C# has nothing to do with C or C++. C# is a runtime environment type of code, that is similar to java in syntax (and in requiring a runtime environment, and in introducing inefficiency to the code due to it), Easier to program in, but makes inefficient programs that can only run on machines with a .net environment, which is not supported anywhere but windows (countering the sole reason why such a model is tolerable with java).

I never said anything about the performance of programs under larabee. In fact you are probably quite right (we'll need to see benchmarks first) The only reason it would be any better is that Intel tends to do a really good job with their compilers.

C# has about as much to do with C++ as C++ has to do with C. That was my point. C# has a somewhat similar syntax to C++. But you are also wrong about C# only being supported on windows under the .net environment. Mono is a cross platform C# compiler. The reason for the creation of C# was to make a C++ like language that had RAD capabilities. It does a good job at that. The extra overhead from having to call the .Net libraries is almost always a moot point.

 

[Fox5]

Originally posted by: Cogman

Originally posted by: Fox5

Originally posted by: magreen
So it actually is binary compatible, despite what Jen Hsun said (and Anand seemed to tacitly agree with) ?

Many programs nowadays assume at least SSE, some SSE2.

Also, x86-64 requires SSE2.

No, x86-64 does not require SSE2. SSE2 is included because it adds a fairly good performance increase across a large board of applications. MMX, 3dNow. ect are all not required by any x86 standard, but added features for faster processing.

I'm pretty sure x86-64 added in SSE2 as a requirement, despite it's optional status previously. A 64 bit program does not have to use SSE2, but part of the x86-64 specification says it should be there.

 

[Cogman]

Originally posted by: Fox5
I'm pretty sure x86-64 added in SSE2 as a requirement, despite it's optional status previously. A 64 bit program does not have to use SSE2, but part of the x86-64 specification says it should be there.

I've done a bit of searching and the only thing I can find on this is that every processor that has the x86-64 instruction set has SSE2. As a result they decided to cancel the extra math instruction set from x87. However, I haven't read anything to say that it is part of the x86-64 standard.

If you have a link that says otherwise I would be interested in reading it.