Live data from Hacker News

A new Intel Itanium (IA-64) emulator that boots Windows

raymii.org

11–20 of 83 posts

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#11
post #7
post #5

Earlier quoted context omitted.

I wish this could make it to qemu's main branch; always fun to preserve new systems. I wonder if it runs openvms/ia64 too!

I think most of the machines that could run Windows could also run OpenVMS. It’s a bit unfortunate the company behind the OS needs to make money off its licenses though.

don't they still give some hobbyist licenses?

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#13

Neat I did this on real hardware twenty plus years ago. Also tried Debian, iirc. My memory is that the workstation perf was decent but the thing was loud and used a lot of power. x86 emulation was slow. The nick, Itanic was mostly deserved.

The ia64 more complex compiler ecosystem made it difficult or impossible to port performant programs to the platform. Amd64 allowed people to keep building and running most programs with little understanding of what was happening in the architectural layers.

Even the 800lb guerilla Intel had to acknowledge amd64 was the next step, or it could end up a niche use chip like PowerPC.

The moral of the story is usability matters with consumer chip architecture. =3

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#14
post #6

“It runs quite slowly, (486-levels of performance on a Ryzen 5000 series according to this discord channel)” I’m sure there’s a joke about that being a huge leap in performance for Windows on IA-64 over the past 23 years waiting to be made from this.

To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#16
post #6

“It runs quite slowly, (486-levels of performance on a Ryzen 5000 series according to this discord channel)” I’m sure there’s a joke about that being a huge leap in performance for Windows on IA-64 over the past 23 years waiting to be made from this.

To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3

Yeah EPIC pushed too much effort onto compilers and removed the context awareness of out of order reordering etc and the result was just a lame duck.

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#19
post #2

What's even crazier is that someone vibe-coded ia64 emulation support for QEMU: https://github.com/syunnPC/qemu-system-ia64

Well, that's one vibe coded backburner'd project I can mark off my list...though maybe it would still be helpful so I'll link it here: https://github.com/ChickenParts/qemu-ia64

It booted Linux fine, was working on booting IPF EFI firmware when I got distracted by life and other projects.

Re: A new Intel Itanium (IA-64) emulator that boots Windows

#20
post #6

“It runs quite slowly, (486-levels of performance on a Ryzen 5000 series according to this discord channel)” I’m sure there’s a joke about that being a huge leap in performance for Windows on IA-64 over the past 23 years waiting to be made from this.

To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3

No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded, you stall while an OoO processor keeps going and a speculative OoO processor even keeps guessing. With multiple workloads on the same hardware (virtualization, multitasking, multitenancy) this becomes an intractable problem even in the presence of the magic compiler which can solve for software based unpredictability (branch likelihood and pointer chasing), because every context switch clobbers an unknown set of cache lines and blows the entire thing up.

VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload.

Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.

Post reply on HN