Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Itanium architecture is a weird weird architecture. It's not weird in the sense of Alpha's weirdness (e.g., the super weak memory model), which can be fairly easily compensated for, but it's weird in several ways that make me just stare at the manual and go "how are you supposed to write a compiler for this?" It's something that requires a sufficiently smart compiler to get good performance, while at the same time so designed as to make writing that sufficiently smart compiler effectively compiled.

It wouldn't surprise me if Itanium actually had pretty compelling SPECint numbers. But a lot of those compelling numbers would have come from massive overtuning of the compiler to the benchmark specifically. Something that's going to be especially painful for I/O-heavy workloads is that the gargantuan register files make any context switch painfully slow.



> It wouldn't surprise me if Itanium actually had pretty compelling SPECint numbers.

This was one of the more confusing things about Itanium. It's specifications on paper were really impressive. It had crazy high benchmark results (SPEC, Linpack, etc) compared to similarly clocked competing chips. If real world code behaved like those benchmarks Itanium would have blown other chips out of the water.

I don't know if I've ever seen real-world tests showing the Itanium getting anywhere near the performance of its benchmarks. Intel was also charging a huge premium for the privilege.


Some of those results were due to the substantially better memory subsystem that itanics had compared to x86 systems of the time.


By the time this PDF deck dropped, AMD K10 / Opteron was out, and that ship had sailed.

By 2004 the only thing Itanium had going for it vs a similarly sized Opteron system was the enormous L3 cache. Real good for SPECfp, I guess.


Context switches and interrupts were also pretty quick on itanic as well. Modern x86 has so much cruft that it Would Be Nice if those parts could be re-architected, but it's more like to just become more legacy baggage carried on into future CPU generations.


> "how are you supposed to write a compiler for this?"

It's been a while so I probably am misremembering the terminology, but I was always amused with the dynamic profile/feedback system that I always imagined would be more useful for a JIT code generator or JVM style runtime than a traditional compiler.


There exists a co-evolution between compilers, programming languages and CPUs (or more generally ASICs). I consider it to be very plausible that it is quite possible to develop a programming language that makes it sufficiently easy for a programmer to write performant code for an Itanium, but such a programming language would look different from C or C++.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: