Is a repeat of AMD64 vs. IA64 coming up?

AtWork · **Joined:** Tue Jul 31, 2007 1:25 pm **Posts:** 200

From a recent Ars Technica article:

Quote:

This incremental approach fits well with what has worked for AMD in the past, and in hearing Akrout describe it I had a sudden flashback to a previous time when Intel expected everyone to ditch their legacy code and dive right into a radically different architecture. I'm talking, of course, about IA-64, which was originally planned as the 64-bit replacement for x86. I'll leave IA-64's absolute success or failure for the market a question for the graybeards to fight over, but there's no denying that the move left a huge opening for AMD's wildly successful x86-64 move. (The Larrabee/IA-64 parallels actually go even further: both were massively delayed, and it's likely when Larrabee drops that initial performance will underwhelm, just like Itanium.)

It's entirely possible that Intel will sink a ton of effort and money into Larrabee, only to see it upstaged by a much-less-daring approach from AMD. But, of course, in the long run, everyone has to deal with the fact that the future for all processors, data-parallel and otherwise, looks a lot like Larrabee in one respect: support for way more threads than we currently have any idea how to put to good use.

http://arstechnica.com/hardware/news/20 ... mpaign=rss

cheesybagel · **Joined:** Tue Aug 18, 2009 5:57 pm **Posts:** 30

Itanium was not the first time Intel did something like that. i860 and iAPX 432 came before. But I still think Larrabee is useful. I suspect even if it never gets much traction as a GPU the technology will be incorporated into CPUs or hybrids somehow. Especially that 512-bit vector unit.

DavidC1 · **Joined:** Wed Aug 15, 2007 3:06 am **Posts:** 51

cheesybagel wrote:

Itanium was not the first time Intel did something like that. i860 and iAPX 432 came before. But I still think Larrabee is useful. I suspect even if it never gets much traction as a GPU the technology will be incorporated into CPUs or hybrids somehow. Especially that 512-bit vector unit.

At this point, I am prepared to accept that we'll see a 500mm2, Radeon 4600 early next year. Big delays like this on CPUs impact final performance by something around 50%, how bad will it for Larrabee as compared to if wasn't delayed? 2x?

What's next? DP FP performance on the levels of GF8800? Gulftown-like Ray Tracing performance? Hah!

Johan · **Posted:** Sun Nov 15, 2009 11:14 am

Quote:

everyone has to deal with the fact that the future for all processors, data-parallel and otherwise, looks a lot like Larrabee in one respect: support for way more threads than we currently have any idea how to put to good use.

I am sorry but I don't buy that. It is called the holy grail of computer science ("almost every algorithm highly parallel"), and we have been searching about 20 years for it. It is an imaginary holy grail, a mystical ghost that is unlikely to be found because it does not exist. The reason why Fusion and Larrabee are good ideas is not that one day we 'll be able to put enormous amount of threads to good use, but to have processing chips that can do the same tasks as the current GPU + CPU combination but with higher performance and less energy , in a smaller form factor. The highly serial, hardly parallel CPU is not going to go away in the next decade and is NOT going to be replaced by "super parallel chip". Chances are very high that the our good old serial processor will always find a place under the heatspreader of any electronic device as part of a larger hybrid processor .

MadRat · **Joined:** Sun Jul 22, 2007 12:53 am **Posts:** 214

With the size of the chip shrinking every couple of years the whole cpu thing will just a minor component. Seems like we've already reached the point where they started putting more effort into the bus and caches than the actual cpu itself. I wonder why some of the traditional south bridge extensions, like sound, aren't integrated into the cpu cores by now. Seems like they could have made a pretty generic pci-e interface that is standardized between platforms to obsolete the whole low end sound card industry, just like they've largely done to the low end graphics industry.

rcf · **Joined:** Tue Oct 02, 2007 2:17 pm **Posts:** 103

Quote:

This incremental approach fits well with what has worked for AMD in the past, and in hearing Akrout describe it I had a sudden flashback to a previous time when Intel expected everyone to ditch their legacy code and dive right into a radically different architecture. I'm talking, of course, about IA-64, which was originally planned as the 64-bit replacement for x86. I'll leave IA-64's absolute success or failure for the market a question for the graybeards to fight over, but there's no denying that the move left a huge opening for AMD's wildly successful x86-64 move. (The Larrabee/IA-64 parallels actually go even further: both were massively delayed, and it's likely when Larrabee drops that initial performance will underwhelm, just like Itanium.)

Well, according to Andy Glew at comp.arch, the core of the Larrabee team consists of the people who gave us Itanium.

Paul DeMone · **Posted:** Sun Nov 15, 2009 5:28 pm

rcf wrote:

Quote:

This incremental approach fits well with what has worked for AMD in the past, and in hearing Akrout describe it I had a sudden flashback to a previous time when Intel expected everyone to ditch their legacy code and dive right into a radically different architecture. I'm talking, of course, about IA-64, which was originally planned as the 64-bit replacement for x86. I'll leave IA-64's absolute success or failure for the market a question for the graybeards to fight over, but there's no denying that the move left a huge opening for AMD's wildly successful x86-64 move. (The Larrabee/IA-64 parallels actually go even further: both were massively delayed, and it's likely when Larrabee drops that initial performance will underwhelm, just like Itanium.)

Well, according to Andy Glew at comp.arch, the core of the Larrabee team consists of the people who gave us Itanium.

Really? What are their names?

rcf · **Joined:** Tue Oct 02, 2007 2:17 pm **Posts:** 103

Paul DeMone wrote:

Really? What are their names?

Go to comp.arch and ask Andy Glew directly.

Paul DeMone · **Posted:** Sun Nov 15, 2009 5:42 pm

rcf wrote:

Paul DeMone wrote:

Really? What are their names?

Go to comp.arch and ask Andy Glew directly.

Nice cop out.

The accounts I have read say that Larrabee was pushed forward by former P4 folks
like Glenn Hinton, Doug Carmean, and Eric Sprangle. Here is one example:

http://www.ddj.com/architect/216402188?pgno=1

Of course some x86 folks would probably prefer to publically assign Larrabee difficulties
to unnamed IPF folks. Still not a lot of love lost between the two camps, particularly
among the old timers.

rcf · **Joined:** Tue Oct 02, 2007 2:17 pm **Posts:** 103

Paul DeMone wrote:

Nice cop out.

I shouldn't have said "core", but I wrote from memory. Here's the original:

Andy Glew wrote:

Some of the people who brought you Itanium, who drank the VLIW koolaid,
are the people who are bringing you Larrabee. 'Nuff said.

http://groups.google.com/group/comp.arch/msg/c4f7e2d717b40f4e

He also says that P4 was originally in-order.

Hans de Vries · **Joined:** Tue Aug 07, 2007 11:57 am **Posts:** 190

Larrabee is mainly an initiative of Doug Carmean and Eric Sprangle
who were behind the original attempt to design an ultra-pipe processor
with ~50 to 60 processor stages. (Called the Nehalem before this name
went to the current Core2 based design)

Some reason more to belief/suspect that Larrabee's 512 bit SSE units
are actually quadruple clocked 128 bit units with the pipeline-stages
divided in four equal timing paths.

(Thirty two full 512 bit SSE units would take around 900 mm^2 in 45nm
and would be a pretty big waste of die space in my opinion for all
software which can't use 512 bit SSE vectors)

The SSE units are the units which are the most easily to hyper-pipeline
since the lack of memory-type macros. (provided that physical synthesis
is perfected enough)

Of course one could extend the quadruple clocking for the rest as well
in the future (For four separate threads which is doable. Easier than doing
it for a single thread which is highly complex and inefficient)

Regards, Hans

EduardoS · **Joined:** Sat Mar 22, 2008 5:10 pm **Posts:** 224

But Hans, SSE units on current processors are so big because they must have a small latency, for a GPU latency isn't so important so they could save area, no need to waste 900mm²...

Hans de Vries · **Joined:** Tue Aug 07, 2007 11:57 am **Posts:** 190

EduardoS wrote:

But Hans, SSE units on current processors are so big because they must have a small latency, for a GPU latency isn't so important so they could save area, no need to waste 900mm²...

Well the die-shots of SandyBridge strongly suggest something similar:
A double clocking of the SSE pipelines (in this case) because there is
no relevant change in relative core area and here the latency remains
essential.

Most important is the logic: Using large amounts of SSE logic for very wide
SSE words reduces significantly the area efficiency and power efficiency of
the processor for every type of software which doesn't use the 256 bit or
the 512 bit words.

Regards, Hans

EduardoS · **Joined:** Sat Mar 22, 2008 5:10 pm **Posts:** 224

Hans de Vries wrote:

Most important is the logic: Using large amounts of SSE logic for very wide
SSE words reduces significantly the area efficiency and power efficiency of
the processor for every type of software which doesn't use the 256 bit or
the 512 bit words.

True, and for this reason I think it's too stupid to increase SIMD in an archteture gradually through extensions, if Larrabee wasn't x86 there would be no legacy latency sensitive software using 128-bit vectors to care about, well, this isn't a big problem for Larrabee but may be for Sandy Bridge sucessor if AVX is futher extended.

I mean... There are a lot (well... not so lot... But only vectorized ones are important here) of software wich rely on 128-bit vector because SSE have a fixed width not because the algorythm only needs 128-bit vectors.

Eric Bron · **Posted:** Mon Nov 16, 2009 12:39 am

EduardoS wrote:

if Larrabee wasn't x86 there would be no legacy latency sensitive software using 128-bit vectors to care about

we are not sure at this point if Larrabee will indeed support SSEx (or even x87), see this old discussion for example :
http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/68043/

Aceshardware

Is a repeat of AMD64 vs. IA64 coming up?

Who is online