HP stepping away from Itanium

[VirtualLarry]

And x64 was a terrible hotfix solution to the real problem ahead. And you should know that by now.

It was a natural, and needed, logical evolution.

I think that you are just moaning about it because AMD invented it. If Intel had invented it, you would think it's like the holy grail.

 

[waffleironhead]

No, the IA64 ISA isn't great. I really wanted to like it, but it's too complex and puts too much emphasis on compiler ability to generate good code for a quite complex ISA.

Sounds like AMD's complaints about bulldozer adoption. "The hardware is amazing, compilers just can't properly handle our awesome sauce."

 

[Arachnotronic]

It was a natural, and needed, logical evolution.

I think that you are just moaning about it because AMD invented it. If Intel had invented it, you would think it's like the holy grail.

From what the ARM folks claim, X86/X86-64 has a lot of baggage that makes processors built on that ISA relatively difficult to design compared to a "cleaner" ISA like ARMv8.

No idea what this translates into in the real-world (i.e. take the same exact team with the same exact $ budget and build the best processor possible in a given die/thermal envelope), but if it's material, ShintaiDK may be correct in the general observation.

 

[ShintaiDK]

From what the ARM folks claim, X86/X86-64 has a lot of baggage that makes processors built on that ISA relatively difficult to design compared to a "cleaner" ISA like ARMv8.

No idea what this translates into in the real-world (i.e. take the same exact team with the same exact $ budget and build the best processor possible in a given die/thermal envelope), but if it's material, ShintaiDK may be correct in the general observation.

Yep. IA64 cores are smaller, wider (12 issue wide currently), more power efficient and clean 64bit without the heavy legacy burden.

 

[ShintaiDK]

Sounds like AMD's complaints about bulldozer adoption. "The hardware is amazing, compilers just can't properly handle our awesome sauce."

Not similar at all. And you have the software running fine. The compilers have matured fine. Its no different really than x86/x64.

IA64 even started out as faster than x86 CPUs, and for a long time it was still faster in FPU. But the aggressive R&D focus on x86 changed that.

The main difference is that an x86/x64 CPU tries in realtime to guess instruction dependencies. While with IA64 you do it at the compiling. So instead of having to use a lot of power at runtime to get a mediocore result on every single PC. You can use as much time as you want basicly at compile, and remove not only the burden from all the PCs. But also drasticly increase the speed due to increased CPU width that you can fill.

 

[SunburstLP]

Sounds like AMD's complaints about bulldozer adoption. "The hardware is amazing, compilers just can't properly handle our awesome sauce."

Off-topic:

I don't want to sound like one of those guys, but there is a smidgen of merit to that notion. There are OSes outside of Windows where the performance disparity isn't as great as you would think. I've not seen the right kind of comparison to simply lay the blame at the feet of the compilers. It just _seems_ the most likely culprit. This has me thinking... maybe a few of us should email Michael at phoronix and see if he could come up with a good methodology to compare W7 vs W8 vs practically any linux distro. I've seen him bench different versions of GCC, I've seen LLVM, CLANG and GCC, but I don't think I've seen him do Win vs Linux with just GCC compiled software.

On-topic:

I had high hopes for IA64's performance while disliking the departure from a traditional ISA. I've never much cared for proprietary things as they can sometimes force industries to make some serious fiscal compromises in order to migrate their programs. I'll have a beer to celebrate the incredible engineering that just didn't work out.

 

[Arachnotronic]

Not similar at all. And you have the software running fine. The compilers have matured fine. Its no different really than x86/x64.

IA64 even started out as faster than x86 CPUs, and for a long time it was still faster in FPU. But the aggressive R&D focus on x86 changed that.

The main difference is that an x86/x64 CPU tries in realtime to guess instruction dependencies. While with IA64 you do it at the compiling. So instead of having to use a lot of power at runtime to get a mediocore result on every single PC. You can use as much time as you want basicly at compile, and remove not only the burden from all the PCs. But also drasticly increase the speed due to increased CPU width that you can fill.

So I take it you may be a fan of NVIDIA's Denver?

 

[jhu]

So I take it you may be a fan of NVIDIA's Denver?

Or older Radeons?

 

[jhu]

Doesn't really matter to Intel since HP was essentially outsourcing their CPU development to them. It's interesting that Itanium revenue was still greater than AMD's entire revenue, and HP was the one essentially funding the whole thing. I can see why they'd finally want to stop this.

Although Itanium does have some RAS features that I don't think Xeon has yet.

 

[ThatBuzzkiller]

Itanium never had a future to begin with ...

 

[videogames101]

I know a few guys on this forum worked on these chips, sucks for the designers who invested so much time and effort into it.

 

[beginner99]

Yep. IA64 cores are smaller, wider (12 issue wide currently), more power efficient and clean 64bit without the heavy legacy burden.

given the fact that I'm writing this on 32-bit windows because the company I work for this has 16-bit apps so 64-bit windows was a no-go tells you that moving every single legacy software to a new ISA will take decades. hence you need something compatible with legacy stuff. So it's entire a matter of optinion if being legacy compatible is bad or good.

From a pure technical standpoint it's bad but from a practical and economical standpoint it's required. Power is cheap. Cheaper to use more power than migrate all software.

 

[Nothingness]

The main difference is that an x86/x64 CPU tries in realtime to guess instruction dependencies. While with IA64 you do it at the compiling. So instead of having to use a lot of power at runtime to get a mediocore result on every single PC. You can use as much time as you want basicly at compile, and remove not only the burden from all the PCs. But also drasticly increase the speed due to increased CPU width that you can fill.

I disagree: out of order execution is the only way to absorb unexpected L1 cache misses for instance and these misses will happen unless your workload is HW prefetch friendly (which is the case of some FP workloads hence the excellent results of Itanium on such tasks). Compilers can't predict and get around all of these misses.

 

[DrMrLordX]

given the fact that I'm writing this on 32-bit windows because the company I work for this has 16-bit apps so 64-bit windows was a no-go tells you that moving every single legacy software to a new ISA will take decades. hence you need something compatible with legacy stuff. So it's entire a matter of optinion if being legacy compatible is bad or good.

From a pure technical standpoint it's bad but from a practical and economical standpoint it's required. Power is cheap. Cheaper to use more power than migrate all software.

I'm a little surprised they haven't gone to VMs for that legacy software. Some reason why they can't or won't do that?

 

[fire400]

wherever the cash flow is, that's what gets a lot of attention in the market.

software coding is moving at an accelerating rate in R&D. however, what must be questionable for the consumer market is big businesses settling for mediocre hardware that accommodates brilliant R&D code with terrible code stacking for market appeal.
release date pressure towards software engineers, for example, some not using proper error correction handling.

the interesting thing here is how to maximize profit with as few resources and little pay out as possible. we're at the beginning stages of dramatic recursive artificial intelligence. how many times will a computer prompt its end-user, dictations and further directions before it can function on its own, and how long can it sustain with or without human input?

the traditional x86 processor will change eventually, where the software alone, similar to BIOS and OS, is more self-aware of changes, such trigger points as UEFI and embedded identifiers, trickled down from defense technologies and high-end data centers.
it's a pretty steep well of advanced technologies, laid out clearly from the earlier birth of the 1900's, in computer science, when pioneers knew the landscape would ultimately be limitless to anyone with the fundamentals and corporation-funded-research breakthroughs.

sure, the cpu, it crunches data. smart phones offer multi-tasking capability, yes. "smart things" will become the norm and trend of the next ten years, and so forth.
the software code similar to codecs, will eventually be injected directly into the mainstream consumer processors, just as we are seeing with SSD's.
an example, the SSD has a 'controller' of its own, but is utilizing firmware. the firmware can be updated to change the behavior of the built-in software, etc. therefore on external level, we think we're controlling the data of our storage device, but in reality, the SSD "regulates for us," the concept is, allowing us to write to it when certain variables have been met.

technology devices are becoming tightly integrated, and software coding is becoming much more dynamic and self-corrective/correcting.

what can human hands do, that the brain can't do, to allow a computer system to create a work of art, similar to a hand-painted canvas?
intel is adapting and staying as close as possible to their vision of moore's law. to sustain R&D, their market vision of ever increasing profits is vital. they will contract as they need, to push forward innovation and profitability.
hp, on the other hand, seems to be trying to replicate IBM's business model - anyone & anything, can become a cloning company, but what makes a true innovator and trend setter? big companies want to patent research and control market share as much as possible in their favor.

the forecast for goods and services have changed rapidly from decade to decade. cash in, cash out.
because there is enough money floating around the economy, there is enough technology to abandon, but not enough people to fill every job out there, for whatever damn reason...

solution, it seems...
build faster and faster computers to crunch more data and work faster and harder than humans can ever comprehend.

*-*

 

[NTMBK]

There are plenty of cases in which static scheduling cannot extract parallelism that dynamic scheduling can, cache stalls being the obvious one. Even Itanium moved to out-of-order execution with the Poulson core.

And while the early Itaniums had small cores, they required massive caches to compensate for their cache-sensitivity- you still end up with a massive die.

 

[Idontcare]

I know a few guys on this forum worked on these chips, sucks for the designers who invested so much time and effort into it.

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.

 

[beginner99]

I'm a little surprised they haven't gone to VMs for that legacy software. Some reason why they can't or won't do that?

No idea.

 

[witeken]

From what the ARM folks claim, X86/X86-64 has a lot of baggage that makes processors built on that ISA relatively difficult to design compared to a "cleaner" ISA like ARMv8.

What do you think ARM would say about any ISA that is not ARM? That it's in fact superior to ARM and people should go with IA instead?

 

[Nothingness]

What do you think ARM would say about any ISA that is not ARM? That it's in fact superior to ARM and people should go with IA instead?

Except that in that case they are 100% correct: x86, 64-bit or not, has a lot of baggage, that can't be denied. And AArch64 has little baggage, that can't be denied.

 

[witeken]

Except that in that case they are 100% correct: x86, 64-bit or not, has a lot of baggage, that can't be denied. And AArch64 has little baggage, that can't be denied.

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.

 

[ShintaiDK]

One of the key benefits of x86 is its legacy. And its true what ARM say.

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

 

[ShintaiDK]

So I take it you may be a fan of NVIDIA's Denver?

Or older Radeons?

How are these relevant to EPIC?

 

[ShintaiDK]

And while the early Itaniums had small cores, they required massive caches to compensate for their cache-sensitivity- you still end up with a massive die.

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

 

[NTMBK]

How are these relevant to EPIC?

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.)