Live data from Hacker News

Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

phoronix.com

121–130 of 220 posts

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#121
post #105

Earlier quoted context omitted.

Alpha would have been such a better path to follow, and Intel even ended up with a license for it because of Compaq/HP's incompetence.

Alpha was unequivocally terrible though. "Better than Itanium" is really not saying much. * no byte operations * no flags, thus no reasonable way to check for overflow (similar to one of the problems RISC-V is having, though at least they pretend to care).

Also “notoriously weak” memory model even as multithreading was taking off, and

> The processor may lose track of your LDx_L if you perform any memory access other than a matching STx_C, or if you perform a branch instruction, or if you trigger a trap (such as executing an emulated instruction), or if you execute more than 20 instructions after the LDx_L.

(LDxL and STxC are locked load and conditional store)

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#122
post #105

Earlier quoted context omitted.

Alpha would have been such a better path to follow, and Intel even ended up with a license for it because of Compaq/HP's incompetence.

Alpha was unequivocally terrible though. "Better than Itanium" is really not saying much. * no byte operations * no flags, thus no reasonable way to check for overflow (similar to one of the problems RISC-V is having, though at least they pretend to care).

IIRC they did add byte operations pretty soon after the initial generation.

The memory consistency model was pretty crazy, though.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#123
post #6

On the one hand, I am not surprised -- at my workplace, we only ever had one Itanium system, an SGI Altix 3000-series computer. It was kind of niche even when we bought it, and core-for-core, the Itanium CPUs were slower than their competitors. What the SGI was really good at was MPI parallelism. I don't know how much of that was the CPU and how much was the overall system design of the Altix, which featured a pretty…

It's not a shame. IA64 did more harm than good for the humanity and the computing industry. It was a dead-end architecture that should have died sooner than it did. Hubris and inertia kept it going much longer than it should have, and delayed so much of other progress. I would say good riddance.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#124

The worst thing about Itanium is that it killed DEC Alpha, high-performance MIPS and some other arches I keep forgetting about.

Jim Keller has stated in at least one talk that DEC went bankrupt after Windows NT on Alpha kept crashing because they'd designed the Alpha with weak memory ordering and MS wouldn't implement the necessary memory barriers.

Didn't sound like Itanic played a part at all.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#126
post #73

Earlier quoted context omitted.

You seem very insightful on this topic. May I ask your opinion as to why ARM is taking off on the server market?

Is it? FAFAIK, the only places where ARM servers run is inside Amazon AWS and Microsoft Azure, and they design their own processors for that. The reason they chose ARM has to do with licensing, it has little to do with the characteristics of the processor architecture nor with processor performance.

Microsoft is using Ampere chips and Ampere has some other clients like Oracle, Hetzner etc. you can use their servers inhouse too.

> with the characteristics of the processor architecture nor with processor performance.

Why did AMD introduce Genoa and Intel is developing equivalent products too? There is market for CPUs with a very high number of low-powers cores and it seems ARM had an advantage there. Even now the price per core (which are good enough for many applications) for Ampere/Gravitron cores is significantly lower.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#127
post #73

Earlier quoted context omitted.

Is it? FAFAIK, the only places where ARM servers run is inside Amazon AWS and Microsoft Azure, and they design their own processors for that. The reason they chose ARM has to do with licensing, it has little to do with the characteristics of the processor architecture nor with processor performance.

Exactly. The year of the ARM server has been predicted for more than 10 years. (Only topped by the year of the Linux desktop, but the latter has probably just been a joke most of the time anyway.)

ARM server has a niche. If Gravitron/Ampere is good enough for your use case and you care about cost they seem like a good deal. AMD/Intel are trying to directly compete with them now with Genoa and Sapphire Rapids.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#129

The chip designers back then were focussed (micro-)instructions per clock (IPC), and everyone knew that RISC and CISC were going to hit a wall due to the ALU bypass network. A this is pretty true, they did, to this day, with some incremental improvements. Folks hoped that VLIW and advanced compilers would take us to the next level of IPC. What they didn't realize was that Itanium wasn't a true VLIW, and had that same…

Yep, the conventional (current) wisdom is that they hit compilers. Itanic was predicated (pun intended) on compilers being able to deliver the parallelism from existing C/C++ apps.

It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.

Re: Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel

#130
post #2

It's funny thinking back to the hype cycle of Itanium back in the heady days where performance was doubling every year, desktop was king and this was the future . Turns out it was more like IBM's MCA / PS2 rather than the future. Compatibility and ubiquity wins. As nearly always.

> Compatibility and ubiquity wins. As nearly always.

Counterexample: GPU compute.

Post reply on HN