HP stepping away from Itanium

[SlowSpyder]

True, same was also true of the Alpha processors. Legends in their time.

This may be the death-toll for Itanium, but I doubt it will simply disappear and never be leveraged in future microarchitectures.

I remember well when the original Pentium Pro was released and tagged as being a total dog in anything that wasn't pure 32bit. It too seemed to have a short life in its future, but it was reincarnated and today's best of the best x86 (Haswell) has quite a bit of the old Pentium Pro still under the hood.

Trial and error is the only way to forward with these things, provided your business is robust enough to survive the error and continue paying for more trials

Itanium certainly didn't bring any lasting harm to Intel, unlike some of the miscues at its competitors.

I remember my first IT job, about 1998 or so. I was just an inventory clerk more or less for the helpdesk / desktop support at the time, really wanted to make it to the helpdesk so I could make the 'big bucks'. (I was 19-20 or so at the time... haha) We used Pentium Pros in our workstations, very nice for what we did. But one of the desktop support guys there had an Alpha server at home he would brag about, 600Mhz. My jaw hit the floor, 600 megahertz. This was in a time of 300MHz Penitum II's and 200Mhz Pentium Pros. Good times!

 

[simboss]

What does that mean quantitatively? Does the development of an IA core cost 2X as much? Does it perform 2X worse and consumes 2X more power? IA has so far not been proven to be meaningfully worse in any way than ARM; what you call baggage is purely subjective.

You know perfectly that you will never get figures for this kind of information, because it's secret and because it's way too complex to give a single figure anyway.
And the cost for Intel or AMD to incrementally develop a "new" core can't be compared with a new one from scratch, regardless of the ISA.

If x86 was an architecture that people could implement, we might have a clue, but it's not the case, so anyone willing to implement a new CPU will go with ARM (or maybe MIPS).

You could try and compare the architecture specification document for both and come up with a conclusion on the complexity, but it is a very hard job.

Bottom line is: we will never know, even comparing the current implementation will not give us a clue as the weight of history is far bigger than the "quality" of the ISA.

 

[NTMBK]

We can say the same thing about x86 cant we? Enterprise class CPUs always have a lot of cache.

Not to the same degree. 180nm Itanium had 4MB of LLC, 180nm Xeon MP had 1MB.

 

[ShintaiDK]

They are VLIW, which is a very close relative of EPIC. They put the burden on static scheduling at compile/optimization time.

(What does EPIC even add over VLIW? The "bundles" concept? That still doesn't solve the forwards compatibility problem entirely- Itanium 2 could schedule instruction combinations which Itanium 1 could not, so to extract full performance you still needed to compile a separate codepath.)

Hardware interlock between dependent instructions.
Accommodates varying number of functional units and latencies.
Allows dynamic scheduling and functional unit binding.
Code size is reduced.
The same code can be executed on different processor implementations (different number of functional units).
Compiler detects ILP and indicates when an instruction cannot be executed in parallel with its successors.

You can also turn it around and say that what they have in common is:
Compiler generated wide instructions.
Static detection of dependencies.
ILP encoded in binary.
Large number of architected registers.

EPIC is an attempt to combine the best from VLIW and superscalar RISC.

 

[Nothingness]

What does that mean quantitatively? Does the development of an IA core cost 2X as much? Does it perform 2X worse and consumes 2X more power? IA has so far not been proven to be meaningfully worse in any way than ARM; what you call baggage is purely subjective.

I was only answering about the baggage thing which again can't be denied. I won't enter an x86 vs ARM ISA war again, it's silly.

However ARM isnt a replacement like IA64 in any way. ARM got the exact same issues as x86.

The 64-bit ARM instruction set (the AArch64 part from ARMv8) was made from scratch. 32-bit compatibility isn't even mandatory. Of course on the system side of the ISA there is some legacy.

 

[ShintaiDK]

Not to the same degree. 180nm Itanium had 4MB of LLC, 180nm Xeon MP had 1MB.

But the Foster MP had 256KB L2 vs the 96KB for Itanium. And x86 at the time was nowhere near the same enterprise class. With the 1½/3M McKinley with 256KB L2 the cache size was reduced.

But it was also faster than any x86 at the time. And you could get 1.5MB Itanium 2 as well. Plus one of the reasons you had more cache was that Itanium could scale to more sockets than the Xeon MP could.

The most modern compare you can do is E7 vs Poulson. But its still not apples ot apples. And you end up with 30M vs 32M while Poulson still scales to more sockets.

 

[ShintaiDK]

The 64-bit ARM instruction set (the AArch64 part from ARMv8) was made from scratch. 32-bit compatibility isn't even mandatory. Of course on the system side of the ISA there is some legacy.

I was thinking in the ability to scale up core width in relation to performance. Not legacy as such. But rather limitations by the design.

 

[Nothingness]

I was thinking in the ability to scale up core width in relation to performance. Not legacy as such. But rather limitations by the design.

Oh I see and I certainly agree with you

OTOH I'm not sure what IA-64 brings to the table that would benefit general purpose code (note that I see what it brings for HPC).

 

[videogames101]

I mean any engineer who looks at x86 and at ARMv8 will tell you ARMv8 is more elegant, but tbh that doesn't necessarily mean shit when it comes to products.