Windows XP 2002 for the Itanium: Unbridled rage
virtuallyfun.com
Windows XP 2002 for the Itanium: Unbridled rage
1–10 of 90 posts
Re: Windows XP 2002 for the Itanium: Unbridled rage
#2I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore
Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
Re: Windows XP 2002 for the Itanium: Unbridled rage
#3I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
I think it died before that, it was just that buried it then.
Re: Windows XP 2002 for the Itanium: Unbridled rage
#4I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
[dead]
Re: Windows XP 2002 for the Itanium: Unbridled rage
#5A historical note: Windows XP 64-bit Edition that was mentioned in the article, was Itanium-specific. It was based on XP kernel while Windows XP x64 Edition (for AMD64 architecture) was based on Windows Server 2003 kernel. Because of that, Windows XP x64 Edition had some significantly different performance characteristics compared to other Windows XP editions. If anything, it was closer to Vista than XP in some aspects.
Re: Windows XP 2002 for the Itanium: Unbridled rage
#6I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO core uses for internal bookkeeping, just exposed architecturally).
I just think the arch has a similarity to archs like cell where it was planned for a world without the end of dennard scaling and just stopped making sense when we weren't targeting scaling to 10Ghz consumer CPUs and beyond.
The relatively fixed clock period that makes sense post ~2006 also means that the CPU architecture of that made the most sense ~2006 (Tomasulo OoO cores) continues to make sense, with most of the process gains going to just making bigger, wider cores.
Re: Windows XP 2002 for the Itanium: Unbridled rage
#7I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
People have tried all kinds of techniques for VLIW, including techniques that are much better than a purpose built AI, AI isn't a magic silver bullet. Fundamentally there's no reason you can't analyse a piece of code to death, and maximally extract parallelism out of it
The fundamental issue is that there simply doesn't exist enough information to be able to extract the necessary parallelism without a rewrite, its the same issue as trying to autovectorise. You can do it to some degree, but it doesn't work in practice to be able to fill out a very wide architecture with reasonable efficacy
The SIMT programming model has proven to be much more successful vs trying to autovectorise or mash things into a VLIW architecture
Re: Windows XP 2002 for the Itanium: Unbridled rage
#8A historical note: Windows XP 64-bit Edition that was mentioned in the article, was Itanium-specific. It was based on XP kernel while Windows XP x64 Edition (for AMD64 architecture) was based on Windows Server 2003 kernel. Because of that, Windows XP x64 Edition had some significantly different performance characteristics compared to other Windows XP editions. If anything, it was closer to Vista than XP in some aspec…
I would love to read the Microsoft PM spec for this product. Who in the world were they making it for?
Itanium never made it into the consumer-class hardware that was XP’s audience. AFAIK, Intel never even published a roadmap for that to happen!
Maybe a proof of concept they shipped as a demonstration of loyalty to Intel?!
Re: Windows XP 2002 for the Itanium: Unbridled rage
#9I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO c…
[deleted]
Re: Windows XP 2002 for the Itanium: Unbridled rage
#10I miss itanium. I feel like a madman for saying it, but I do. Something about it is just alluring to me. Alas, the problems were too hard to solve or weren't worth solving anymore Ironically, it died around the time LLMs/AI started becoming good. I feel like the compiler problems with vliw could be solved to a degree with a purpose built ai
So I feel like I need to write a blog post about this, but succinctly I think there's a good argument to be made that the issue wasn't the compiler despite popular wisdom. I don't even think it was the nature of unpredictable memory access times either as the itanium has a ton of special architectural hardware to handle unpredictable memory accesses (a lot of which are essentially some of the primitives that an OoO c…
It was also planned for a world where high-end CPUs were differentiated by their ability to run floating-point-heavy workloads with relatively predictable memory access patterns.
The rise of the web—and databases behind it—as the dominant high-end, high-margin workload obsoleted that assumption.
There’s a great presentation floating around where a Compaq-acquired-DEC engineer is trying to justify how great the OpenVMS port from Alpha to Itanium is going, despite benchmarks showing Alpha smoking Itanium running Apache.