More Intel Larrabee info (are we sniffing some new X264 records?? ;))

[TEB]

http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367

[G_M_C]

I've read that artikle, and it sounds interesting. It's effectively a highly threaded (tread-capable) general-purpuse CPU that can run ith x86 code.
The very big advantage of this CPU is that i accepts general C/C++ and x86 assembly, and that there will be optimized compilers availabel for it.

When used as a co-processor (rather than GPU-only) it should be able to boost speed for all CPU-code, including x264.
And than it could be a very usefull addition to our PC's :)

[Sagekilla]

As long as you don't require any futzing like CUDA with a "sort of but not quite C/C++" then that sounds like a great idea..

[lexor]

In related news, Larrabee cores appear to be based on the original Pentium design (http://arstechnica.com/news.ars/post/20080708-intels-larrabee-gpu-based-on-secret-pentagon-tech-sorta.html), refined and cleaned up by Pentagon back when it used it in its own devices.

[G_M_C]

As long as you don't require any futzing like CUDA with a "sort of but not quite C/C++" then that sounds like a great idea..

Nope, as i understand from the artikle it uses "standard" C/C++, it seems you can even use "standard compilers". But the best option would offcourse be a specialized compiler. Intel makes very good compilers, so that wont be a problem.

[EDIT]
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=8
You have two options for harnessing the power of Larrabee: writing standard DirectX/OpenGL code, or writing directly to the hardware using Larrabee C/C++, which as it turns out is standard C (you can use compilers from MS, Intel, GCC, etc...).

[Sharktooth]

nope that's a big mistake. as for CUDA or Stream, co-processors need specialized compilers unless intel or others will make add-ons/support for standard compilers.

[G_M_C]

nope that's a big mistake. as for CUDA or Stream, co-processors need specialized compilers unless intel or others will make add-ons/support for standard compilers.

Not according to the article; It is supposed to be a 32-set Pentiums, so standard C/C++ and/or assembly should work ... at least according to Anand ;)

[lexor]

nope that's a big mistake. as for CUDA or Stream, co-processors need specialized compilers unless intel or others will make add-ons/support for standard compilers.

Neither CUDA nor Stream really applies here. Larrabee is the Jack of all trades, it does everything (or it will try for Intel to practice on, and its successor will do everything). So the whole polling and cooperating of various hardware/resources/architectures and interconnects that CUDA and Streams manage doesn't really come into play. It really is just a giant multicore. Nothing more, nothing less.

[Sharktooth]

Not according to the article; It is supposed to be a 32-set Pentiums, so standard C/C++ and/or assembly should work ... at least according to Anand ;)
if it says that, the article is wrong. x86 code compiled by a standard compiler will be executed by the CPU unless the compiler has support for the co-processor.

Neither CUDA nor Stream really applies here. Larrabee is the Jack of all trades, it does everything (or it will try for Intel to practice on, and its successor will do everything). So the whole polling and cooperating of various hardware/resources/architectures and interconnects that CUDA and Streams manage doesn't really come into play. It really is just a giant multicore. Nothing more, nothing less.
dont be fooled by the propaganda. there's a reason why specialized GPUs are faster doing some calculations than CPUs (x86 is an old and obsolete architecture, its luck was the standardization)... otherwise we wouldnt need uber-fast video cards for playing games.

[lexor]

dont be fooled by the propaganda. there's a reason why specialized GPUs are faster doing some calculations than CPUs.... x86 is an old architecture... otherwise we wouldnt need uber-fast video cards for playing games.
Oh, I made no claims to performance/goodness. I merely said that your claim about Larrabee needing different compilers (like other all-in-one efforts do) isn't really a valid one, in this case.

[Sharktooth]

yes, it is. the compiler must support larrabee or you will need a specialized compiler (like the ICL).
for example, GCC, by default, wont produce executables for larrabee...
and x264 wont go faster just by snapping one of those larrabees in your system.

[G_M_C]

We'll see in a few months / half a year when the first samples and examples come around ;)

Everything else is speculation :D

[Sharktooth]

ask akupenguin or dark_shikari if you dont trust me. nothing is "automatic". support must be added, like threading for multicores, larrabee needs support in the compiler as every co-processor.
the same was for Cell. the compilers needed support for the TMUs otherwise the code will run on the main processor.

[G_M_C]

ask akupenguin or dark_shikari if you dont trust me. nothing is "automatic". support must be added, like threading for multicores, larrabee needs support in the compiler as every co-processor.
the same was for Cell. the compilers needed support for the TMUs otherwise the code will run on the main processor.

I'm not saying i dont trust you (trust me on this :p), i'm just saying that i will wait untill further info comes around before i do more speculation.

Untill then; Anandtech is a good site, with good inside views and knowledge, and it doesnt work on rumors afaik.

[lexor]

yes, it is. the compiler must support larrabee or you will need a specialized compiler (like the ICL).
for example, GCC, by default, wont produce executables for larrabee...
Of course it will, it will compile and run, in fact current x264.exe will run. It's an x86 part.


and x264 wont go faster just by snapping one of those larrabees in your system.
Since when do we need compiler optimization for anything x264? And it should go faster, it's a multicore x86 (maybe x64, dunno yet) part. Just like x264 scales from 2 to 4 cores, it will scale to however many cores Larrabee will have. What will happen is we may finally see where the near linear scaling of x264's multithreaded implementation will begin to fall off.

ask akupenguin or dark_shikari if you dont trust me. nothing is "automatic". support must be added, like threading for multicores, larrabee needs support in the compiler as every co-processor.
the same was for Cell. the compilers needed support for the TMUs otherwise the code will run on the main processor.
That's where your believe goes wrong. Larrabee isn't a co-processor, it's a processor. Don't make it personal though, we do trust you, you are one of the few people on this board who can claim implicit trust of the members.

[Sharktooth]

not optimizations. support... two different things.
you can use an external co-processor by coding support in your app or compiling the code with a compiler which has support for that co-processor.
if that co-processor accepts x86 instructions then you can use x86 code to program it (and it's obvioulsy easier than learning a new language) but it wont run your x86 bins unless they're made to use it... and that requires "support" for that co-processor.
larrabee will be stick on a videocard hence it is a co-processor, like the GPUs (they're coprocessors too). even if it was integrated into the CPU it would have been a co-processor, unless it directly affect the main pipeline flow.
for example x87 (FPU) is a coprocessor and it's integrated into the CPU. at present day all compilers have support for it, but at the beginning it wasnt so.
im not making it personal at all. im trying to explain how things work in a PC.

[Comatose]

I'm very likely to get one if I can encode on it :O

[Sharktooth]

first lets see the performance and the cost.
we dont even know how much "cores" they will have.

[Dark Shikari]

first lets see the performance and the cost.
we dont even know how much "cores" they will have.32, from what I heard.

[Sharktooth]

nice, at least some info... but the performance are yet unknown.

[Inventive Software]

Basing it on the Pentium Ds isn't a bad thing IMO. They had quite a deep pipeline and were mega-fast processing fixed and floating point calculations.

If they can get the software back-end done much better than NVIDIA and AMD, then we'll see whether it's a worthy competitor.

What do we know about memory? Does it use system RAM or GDDRx RAM?

not optimizations. support... two different things.
you can use an external co-processor by coding support in your app or compiling the code with a compiler which has support for that co-processor.
if that co-processor accepts x86 instructions then you can use x86 code to program it (and it's obvioulsy easier than learning a new language) but it wont run your x86 bins unless they're made to use it... and that requires "support" for that co-processor.
larrabee will be stick on a videocard hence it is a co-processor, like the GPUs (they're coprocessors too). even if it was integrated into the CPU it would have been a co-processor, unless it directly affect the main pipeline flow.
for example x87 (FPU) is a coprocessor and it's integrated into the CPU. at present day all compilers have support for it, but at the beginning it wasnt so.
im not making it personal at all. im trying to explain how things work in a PC.

Expect GCC to support it before Intel ships thousand-dollar compilers for Larrabee. ;)

[Sharktooth]

even if GCC will support it, separated bins must be compiled or GCC would need produce multiple codepaths binaries (like ICL).
for optimizations, it would be better to code the support directly into the app, so you wont need a larrabee supporting compiler... but that will be quite hard.

[foxyshadis]

Basing it on the Pentium Ds isn't a bad thing IMO. They had quite a deep pipeline and were mega-fast processing fixed and floating point calculations.

Not Pentium D. The original 75-166MHz Pentium that followed the 486. It's like Pentium M/Core 2 going back to the PIII, only much further back. :p No MMX at all, just APU and FPU.

[Sharktooth]

uhm... intel presented something similar at the previous IDF... massive multithreading, 40+40 parallel low wattage pentium cores, called something like TeraScale... they were not fully x86 compatible at that time though...
we all thought it was a CPU, instead they're pushing it as a co-processor or they just reused the same tech for larrabee...
probably it hasnt the same performance of an actual or future multicore CPU. 80 cores were able to push the perf up to 1TFlop. if 32 is the true number it will be less than half. also actual GPUs have already surpassed the Tflop limit...

[Shinigami-Sama]

and if its an addon card then it might just be useless to many apps due to the latency between the bus and the CPU

[Sharktooth]

it seems to be an addon card. larrabee is like a CPU but it's not a CPU like anand defined it.
latencies are not a problem if you manage to make it do ALL the work or just a to not make it bounce data to and from the addon card.
since larrabee addon card is a sort of videocard with a x86 multicore processor it should be possible. it all depends on intel... the SDK... and the compilers...

[Shinigami-Sama]

it seems to be an addon card. larrabee is like a CPU but it's not a CPU like anand defined it.
latencies are not a problem if you manage to make it do ALL the work or just a to not make it bounce data to and from the addon card.
since larrabee addon card is a sort of videocard with a x86 multicore processor it should be possible. it all depends on intel... the SDK... and the compilers...

as well as how much memory it has to work with

I've got a funny feeling its going to turn out like the physics cards
just another toy with little market penetration

[MfA]

You can certainly use normal C(++) to program this architecture, just don't expect anywhere near the efficiency on the cores you would get on modern CPUs. These cores are harshly cutdown, they are meant to run fiberized code ... and not all code will fit that concept as well as the shader programs it will run as a GPU, also I have my doubts about how well the compiler will be at producing fiberized code without special structuring of the C(++) code.

PS. also no special support for 8 bit integers mentioned, not even SAD ... all integers are promoted to 32 bit in the vector unit.

[woah!]

as well as how much memory it has to work with

I've got a funny feeling its going to turn out like the physics cards
just another toy with little market penetration

lets be honest, intel doesnt do "toy" or the words "little market penetration". if they say they are entering the graphics market, i pity the fool...

32 cores x 2+ghz x 16 wide VPU x 1024 bits-wide, bi-directional ring bus / 160 vector ops per clock doesnt sound like a toy to me...