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.
Itanium had all sorts of specialized machinery so that you could issue a load that's required in the future, and then keep chugging away at the instruction stream, similar to what an OoO processor does with it's reordering logic.
One example was "advanced loads" which allowed you to issue a load as soon as you knew the address, even in the face of potential pointer aliasing in the future, and then later complete the load when you actually hit a data dependency that requires it. https://devblogs.microsoft.com/oldnewthing/20150805-00/?p=91...
Another example is "speculative loads" which lets you issue a load before you even know if it's valid, such as unrolling a loop for an array that you don't know if is a multiple of the unrolled loop chunk length (and therefore might trap with a page fault if fully resolved). https://devblogs.microsoft.com/oldnewthing/20150804-00/?p=91...
These worked well for “known” intra-task pointer aliasing situations, but if you don’t know what will be in cache due to preemption of any kind, you still don’t know how many cycles the speculative loads will take, so you get the same stall risks across a dependency hazard.
OoO cores have load stalls too after preemptions. Even something like a Apple M core basically has to stall if the load has to go out to the memory controller. The goal is to move far enough ahead in the stream that you can at least issue the next load, and advaned loads lets you do that. Some Intel cores will occasionally speculatively predict zero for a load, but AFAIK that got turned off as part of the Spectre mitigations.
The difference is that this is not the programmer's responsibility in modern machines: instead we bake-in some hardware that watches the online state of the machine and then actively decides on what to do.
If you're trying to create a compiler that approaches the effectiveness of this statically, you're condemned to do a ton of extra work (you're essentially writing an emulator for your CPU core, and then a compiler that uses that model to produce optimal code - even then, you might not be accounting for nondeterminism on the actual target machine, and some information is simply not accessible to you when you are not on the target machine)
Once again, Itanium isn't a normal, simple in order core that stalls on loads. It has a big table called the ALAT to allow you to start loads as soon as you know the address, and then finalize them later when you're out of other work to do.
It doesn't require determinism to work. And was designed by people that were quite aware of what the instruction stream looks like to an OoO core as it issues out of the rob.
Itanium had other sins than "magic compiler" woes, or even the inherent unpredictability of memory accesses. Mostly that it, like Cell, and Netburst was designed for a world where dennard scaling didn't end like a brick wall. As well as internal politics of Intel making it so that they were a bit loose and fast with die area.
Yes, I'm pointing out the fact that the programmer is expected to manage the ALAT, and that these machines do not automatically recover from cases where your advanced loads are incorrect. That process is expected to be part of the instruction stream, and [we have collectively learned that] that's an expensive feedback loop.
Yes, it doesn't require determinism to work, but it means that your performance is especially sensitive to nondeterminism because the compiler cannot account for loads and stores that occur online. The SDM (see vol 1, section 9.5.1) describes this idea pretty well.
VLIW is being heavily used in some AI inference tasks (by Apple, AMD, Google, mainly in optimizing latency). It also is a nice way to do inference on edge devices that aren’t using constantly advancing models. It’s pretty much dead in general purpose computing though, and lacks the versatility of GPUs to go beyond inference.
We agree it probably would have still failed, but mostly it was the legacy code-motion compatibility/performance issues that were practically inescapable without refactoring millions of lines of code.
gcc maintained the ia64 target a long time for unclear reasons, but it was also still inefficient on other platforms. The FOSS compiler worked, but that was its only performance metric that counted for many users. =3
Not sure why you think the Intel compilers were a myth, as they are still around working far better than gcc in many use-cases:
The myth I was referring to was the overarching theme that “VLIW would have been practical if only a better compiler existed,” which I don’t believe to be true for modern or Itanium-contemporary general purpose computing patterns.
Indeed, people are still bad a parallelism today, and most compilers still suck at reliably unrolling abstracted concurrent source intended functionality.
Very few modern languages handle parallel scaling gracefully, and bodged on CUDA still isn't great either. As Moore's law ends, people have to reevaluate how they approach traditionally monolithic architectural design. =3
1. VLIW exposes microarchitectural details, locking them in like an ABI. Updates to the microrachitecture will require changes to the ISA, thereby breaking backwards compatibility with every generation.
2. The dominant programming paradigm is sequential code, often just old C code with heavy pointer aliasing and little compile time extractable parallelism. This reduces static parallelism in the code base and shifts it into a runtime problem. The CPU discovers the dependencies at runtime instead. If you built a programming language that exposes more parallelism (think something like ParaSail), this problem wouldn't be as big as it is for C style programming languages.
Nobody will build a language for architectures that suffer from backwards compatibility problems, so why bother? VLIW is primarily suited for ASIPs and not much else.
You've mentioned Intel's compilers a few times but they're not a magic thing that could make Itanic not-suck. Suppose they make general purpose code that's twice as fast as GCC when the whole computer is dedicated to running one specific process. They don't, but let's pretend. Even in that ideal scenario, it falls apart as soon as you're processing unpredictable input. VLIW sucks hard at chewing through data that's not precisely what it's expecting. You could probably make a video codec that performed really well, but it would be impossible to make a database that performed consistently not-badly. It's not that the existing compilers weren't good enough, not even the magic Intel ones. It's that it's not possible to pre-generate VLIW opcodes that do well when the input value isn't a homogeneous stream. Even if Intel's code was 2x better than GCC's — and again, it wasn't — twice abominable was still abominable.
I wasted more time SSHed into an Itanic than most people had to, so I'm speaking from first-hand experience. Some very, very specific Itanium code was a bit faster than the equivalent x86 or similar. That was always some very tightly scoped thing that did the exact same tight loop a gazillion times, like en-/decrypting a data stream. Anything more heterogenous ran poorly, as in multiple times the wall-clock time of the same workload on the x86 server next to it that cost a tenth as much. And that's even when using the magic Intel compilers.
Itanium was bad. The compiler tech didn't exist to make it not-bad, and in retrospect I think it become obvious that it couldn't exist. It wasn't a matter of the compiler authors needing to be clever. It was more like making Itanium live up to the hype required making P=NP.
My point was most modern software developers still do not understand systems at an architectural level. I don't buy the VLIW paradigm was inherently inferior argument, but the code written for it with mystery failure modes at the time was a mess.
And ia64 was only around 23% slower and several times more costly than amd64 options at the time. Both toads had their warts, but one was actually usable by mere mortals.
Its true just about everything either ran slow on not at all on ia64... Thankfully, we were still running Sparc based platforms at that time, as the Intel clown-show still looked like more work. But I do empathize with the ia64 trauma, as the roll out had a lot of collateral damage in some firms as people started jumping ship early to avoid accountability. =3
One immediate advantage that rescheduling-capable cores have that rigid compiler-based ones don’t nor ever would is that reschedules can notice patterns in execution in the current context and keep the ALU fed from well-provisioned caches even going as far as speculative execution. IA-64 and typeless or typed-at-runtime (JIT scripts, for example, like JavaScript or Python) would’ve been implemented very differently on Itanium.
EPIC was Explicit Parallel Instruction Computing, the underlying engineering architecture of AI-64. Epyc is an AMD brand name.
And pivoting to concurrency on a rescheduler-intensive core as opposed to concurrency on a scheduler-based core isn’t very pertinent, particularly since we have 25 years of Moore’s Law between then and now.
"AI" responses are silly, and optimal 24 core count efficiency premise in Desktop applications offer diminishing returns on a highly concurrent 32/64/192 core Epyc line of OoO chips...
How many strings does a Bass play with in water? =3
Itanium is yet another example of how difficult it is to fight software ecosystem momentum.
It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
IIRC Itanium was faster on natively compiled HPC code, presumably because it had more FPUs and larger cache than the Pentium 4. But in general it probably wasn't a good upgrade and Intel would have had to sandbag x86 a lot to force Itanium adoption.
The other problem was that the Pentium 4 itself was kind of a dog, and then the Pentium M and Core lines started making that look bad, by which point the Itanic passengers could feel their socks getting wet and a growing concern about there not being enough life boats.
Agreed, everyone has a pet architecture that fascinates them, but if its so good only 5 people can code for the target... it is e-waste within a year.
Apple is an exception as it has always had a walled-garden ecosystem with the OS, so can force shifts in architectures unlike most companies. The M3/M4 Pro series with unified GPUs is probably the best design on the consumer market right now, but people are not leveraging it as much as they would have in other ecosystems.
Apple is the survivor of another era, people keep forgetting that x86 clones are the exception of how computer market used to be, not the other way around.
The walled garden is an advantage of some sort, but they’ve also never made a bad call on switching architectures.
We don’t know what it would look like if Apple had chosen something that ended up like Itanium. It’s quite possible they don’t have the clout to pull it off.
(Maybe they should have gone Intel instead of PPC, but both were significantly better than m68k at that point)
> they’ve also never made a bad call on switching architectures.
It seems more like they have a high willingness to switch architectures.
Predicting which one is better in the year that you do it or the couple of years after isn't that hard. The question is, where is it going to be in a decade or two?
Each time they picked a huge company you wouldn't have expected to fail in that year, first IBM, then Intel. But that's the problem with huge companies, after a few years on top they tend to get complacent and stagnate.
Now Apple itself is the big company, but it remains to be seen if they're not still going to end up on e.g. RISC-V within the next ten years or so.
I would already be happy if Windows NT had been more serious about UNIX compatibility.
I only bought that Linux Unleashed book in 1995's Summer, because Windows NT wasn't good enough for doing university assignments at home, which used a mix of DG/UX and Solaris on the campus.
I was working for a large bank and it was all windows, including production. We used to run WebSphere Application Server on Windows. I was looking for a dev server to run unit tests on, including integration tests which required an actual WebSphere instance. The infrastructure team said they had “a box” going spare and it turned out to be IA64 on Windows.
If my memory serves me correctly WebSphere only ran on windows for IA-64 up to 6 and we were running on 7.
I had to do a bit of hacking but I did manage to get it working using the dlls from the 6 version. It was fine for running integration tests and a pretty fast box considering.
Am I right to guess that neither your dev nor prod machines ran IA-64? If so that's not ideal, but beggars can't be choosers & a spare box from the infra team available right now is better than getting a box built to meet your exact specs available after the usual multi-quarter internal lead time.
Superficially it sounds a little crazy, but it's probably a lot less crazy than far more mainstream antipatterns (e.g. 'lets have our CI download all the dependencies from npm over the internet each time the build runs')!
Did running the unit tests on IA-64 ever flush out genuine issues that were 'working by accident' on x86?
I would have loved something better but sometimes you just have to make do.
WebSphere was 99% Java (except for a few pesky dlls) and I never saw any oddities, it worked the same as it did on the old x86 VM I had which was woefully under spec. Our entire software platform was on WebSphere.
It really was a meaty box, which was a huge help because the tests originally (before IA64 box) used to take all night to run.
It's interesting to see how LLMs have definitely become a force-multiplier to motivate people into doing things they wouldn't otherwise have the time and effort to.
It really depends on the end goal. For personal tools that one uses, LLMs are extremely useful. But publicly used software doesn't only need to be written - it also needs to be maintained. And considering that it's extremely easy to implement features that are not used, vibe coded software tends to be, in best case, a mixed bag, and in worst (I believe typical) case, quickly abandoned.
Vibe coded software is the modern equivalent of the shovelware of the 90s.
I have been pairing with Claude Opus and it’s quite impressive. I have explored a number of possible changes to things like VTE and the Hercules mainframe emulator.
Sweet. What changes to Hercules have you been considering? I have had a long running (and maintained!) MVS instance in Hercules for quite a few years now, just for fun.
I want a telnet port connecting directly to the Hercules console when it runs headless, as that is the way it ends up running in Docker. The Hercules console does a lot of heavy lifting that could be implemented at the terminal (as even Windows now has a proper terminal). It went as far as allowing me to connect and see the console transcript, which is pretty already.
Another thing I want that I haven't figured out is to print to my network printers - they all do lpr and ipp, but Hercules direct to socket approach didn't work for me and I need to do more research on that. Ideally, the line in the config could be a pipe command where I could turn the page into PostScript to be netcat it to the printer. or massage it through a converter that took in an IBM line printer EBCDIC stream and spat out ASCII for a "normal" printer.
Would be amazing to implement a JIT in hercules (would make it 10x faster potentially as fast as z/PDT which implements a JIT); good timing as IBM is retiring z/PDT!
It's bone crushingly dry to try and figure this kind of shit out yourself, can do everything right according to every available reference and code comment only to get compiler and linker errors nobody has ever seen or posted about. Weeks and weeks of smashing your face against a wall until it gives. Now anyone can get twice as far in an evening. And that fuckin rules
Hard to not get a little hyperbolic about it... but I can't wait for everyone to exhaust their meme projects/ports and models to get just a bit better. Feels like we're about to have something of a golden age when everyone starts really making the stuff they've always wanted.
Recently thanks to Modern Vintage Gamer on youtube, there has been a push to see if you could get Doom to run on the NeoGeo. Because of its very unique hardware (no framebuffer) it is a very unqiue and tough task.
And yet, some folks have come to the battle and have ended up extensively using LLM's to code it. It is wild to see that these things can target such an obscure platform and get some decent results in a very short amount of time.
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.
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.
They are in a tough spot. They have to pick between milking their legacy clients who have been running VMS workloads and don’t want to port them to anything else, and a much more risky attempt to develop a consulting ecosystem so those clients can remain on VMS indefinitely. This ecosystem would eat into their own support business at the expense of reducing incentives to migrate to different platforms.
I'll admit that "OS snob who just wants to run VMS because they once ran it on Alpha" is pretty low on the freebie list, but they didn't even say no, they just strung me along until I gave up caring.
I really wish they released it under a GPL license. Unless an event starts an adoption uptick for greenfield projects (and it'd take some time for that). I wish they had an easy way to deploy an OpenVMS instance on a cloud service the same way IBM does with their POWER and Z machines (sadly, no Linux on POWER from them).
Huh. It looks like they're actually getting rid of their as400 hosting... I wonder what that would have cost, being the only players in the game...
> Images for the Virtual Server for VPC (s390x architecture) are deprecated. Starting 28 February 2026, you can't create new instances from s390x images. Existing instances are supported until 20 February 2027. Any instances that remain after that date are deleted.
This is much harder problem than most CPU emulators as IA-64 isn't really just another ISA. EPIC most significantly allows the RE which seems like the main implementation challenge. Does the emulator model the RSE or are there shortcuts for Windows compatibility? Also, which Windows model is booting?
> In 1994, Intel and HP looked around and saw a wide variety of successful server CPU architectures like Alpha, MIPS, SPARC, and POWER. This annoyed them and they decided to make a new CPU that no one would want to use.
Absolutely. This monstrosity managed to have all what was wrong with CISC and all of the disadvantages of RISC at a higher price point than anything on the market at the time.
Wasn't there a problem with Alpha, that it had too weak memory model or something? Think of atomic instructions with multi CPU system. Or do I remember something wrong?
Alpha was great but that wasn't enough against the convenience of just running an x86 box. It didn't find a niche quickly enough. ARM survived because they were low power. POWER survived because IBM is one big niche. MIPS died and reincarnated into RISC-V. I have no idea where Alpha would have gone had it not been dropped.
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
It would make sense to implement it in QEMU instead. There was some previous work in the past, don't have a link right now to the original patchseries, but here is the repository[1]. In theory, it could be adapted to the modern QEMU code infrastructure and APIs and be a good starting point. Back in the past I started[2] doing that but quickly dropped because had no time to finish.
“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.
Itanium had all sorts of specialized machinery so that you could issue a load that's required in the future, and then keep chugging away at the instruction stream, similar to what an OoO processor does with it's reordering logic.
One example was "advanced loads" which allowed you to issue a load as soon as you knew the address, even in the face of potential pointer aliasing in the future, and then later complete the load when you actually hit a data dependency that requires it. https://devblogs.microsoft.com/oldnewthing/20150805-00/?p=91...
Another example is "speculative loads" which lets you issue a load before you even know if it's valid, such as unrolling a loop for an array that you don't know if is a multiple of the unrolled loop chunk length (and therefore might trap with a page fault if fully resolved). https://devblogs.microsoft.com/oldnewthing/20150804-00/?p=91...
These worked well for “known” intra-task pointer aliasing situations, but if you don’t know what will be in cache due to preemption of any kind, you still don’t know how many cycles the speculative loads will take, so you get the same stall risks across a dependency hazard.
OoO cores have load stalls too after preemptions. Even something like a Apple M core basically has to stall if the load has to go out to the memory controller. The goal is to move far enough ahead in the stream that you can at least issue the next load, and advaned loads lets you do that. Some Intel cores will occasionally speculatively predict zero for a load, but AFAIK that got turned off as part of the Spectre mitigations.
The difference is that this is not the programmer's responsibility in modern machines: instead we bake-in some hardware that watches the online state of the machine and then actively decides on what to do.
If you're trying to create a compiler that approaches the effectiveness of this statically, you're condemned to do a ton of extra work (you're essentially writing an emulator for your CPU core, and then a compiler that uses that model to produce optimal code - even then, you might not be accounting for nondeterminism on the actual target machine, and some information is simply not accessible to you when you are not on the target machine)
Once again, Itanium isn't a normal, simple in order core that stalls on loads. It has a big table called the ALAT to allow you to start loads as soon as you know the address, and then finalize them later when you're out of other work to do.
It doesn't require determinism to work. And was designed by people that were quite aware of what the instruction stream looks like to an OoO core as it issues out of the rob.
Itanium had other sins than "magic compiler" woes, or even the inherent unpredictability of memory accesses. Mostly that it, like Cell, and Netburst was designed for a world where dennard scaling didn't end like a brick wall. As well as internal politics of Intel making it so that they were a bit loose and fast with die area.
Yes, I'm pointing out the fact that the programmer is expected to manage the ALAT, and that these machines do not automatically recover from cases where your advanced loads are incorrect. That process is expected to be part of the instruction stream, and [we have collectively learned that] that's an expensive feedback loop.
Yes, it doesn't require determinism to work, but it means that your performance is especially sensitive to nondeterminism because the compiler cannot account for loads and stores that occur online. The SDM (see vol 1, section 9.5.1) describes this idea pretty well.
VLIW is being heavily used in some AI inference tasks (by Apple, AMD, Google, mainly in optimizing latency). It also is a nice way to do inference on edge devices that aren’t using constantly advancing models. It’s pretty much dead in general purpose computing though, and lacks the versatility of GPUs to go beyond inference.
We agree it probably would have still failed, but mostly it was the legacy code-motion compatibility/performance issues that were practically inescapable without refactoring millions of lines of code.
gcc maintained the ia64 target a long time for unclear reasons, but it was also still inefficient on other platforms. The FOSS compiler worked, but that was its only performance metric that counted for many users. =3
Not sure why you think the Intel compilers were a myth, as they are still around working far better than gcc in many use-cases:
"An Overview of the Intel® IA-64 Compiler"
https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/In...
The myth I was referring to was the overarching theme that “VLIW would have been practical if only a better compiler existed,” which I don’t believe to be true for modern or Itanium-contemporary general purpose computing patterns.
Indeed, people are still bad a parallelism today, and most compilers still suck at reliably unrolling abstracted concurrent source intended functionality.
Very few modern languages handle parallel scaling gracefully, and bodged on CUDA still isn't great either. As Moore's law ends, people have to reevaluate how they approach traditionally monolithic architectural design. =3
Honestly, you're conflating two things.
1. VLIW exposes microarchitectural details, locking them in like an ABI. Updates to the microrachitecture will require changes to the ISA, thereby breaking backwards compatibility with every generation.
2. The dominant programming paradigm is sequential code, often just old C code with heavy pointer aliasing and little compile time extractable parallelism. This reduces static parallelism in the code base and shifts it into a runtime problem. The CPU discovers the dependencies at runtime instead. If you built a programming language that exposes more parallelism (think something like ParaSail), this problem wouldn't be as big as it is for C style programming languages.
Nobody will build a language for architectures that suffer from backwards compatibility problems, so why bother? VLIW is primarily suited for ASIPs and not much else.
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.
[flagged]
You've mentioned Intel's compilers a few times but they're not a magic thing that could make Itanic not-suck. Suppose they make general purpose code that's twice as fast as GCC when the whole computer is dedicated to running one specific process. They don't, but let's pretend. Even in that ideal scenario, it falls apart as soon as you're processing unpredictable input. VLIW sucks hard at chewing through data that's not precisely what it's expecting. You could probably make a video codec that performed really well, but it would be impossible to make a database that performed consistently not-badly. It's not that the existing compilers weren't good enough, not even the magic Intel ones. It's that it's not possible to pre-generate VLIW opcodes that do well when the input value isn't a homogeneous stream. Even if Intel's code was 2x better than GCC's — and again, it wasn't — twice abominable was still abominable.
I wasted more time SSHed into an Itanic than most people had to, so I'm speaking from first-hand experience. Some very, very specific Itanium code was a bit faster than the equivalent x86 or similar. That was always some very tightly scoped thing that did the exact same tight loop a gazillion times, like en-/decrypting a data stream. Anything more heterogenous ran poorly, as in multiple times the wall-clock time of the same workload on the x86 server next to it that cost a tenth as much. And that's even when using the magic Intel compilers.
Itanium was bad. The compiler tech didn't exist to make it not-bad, and in retrospect I think it become obvious that it couldn't exist. It wasn't a matter of the compiler authors needing to be clever. It was more like making Itanium live up to the hype required making P=NP.
My point was most modern software developers still do not understand systems at an architectural level. I don't buy the VLIW paradigm was inherently inferior argument, but the code written for it with mystery failure modes at the time was a mess.
And ia64 was only around 23% slower and several times more costly than amd64 options at the time. Both toads had their warts, but one was actually usable by mere mortals.
Its true just about everything either ran slow on not at all on ia64... Thankfully, we were still running Sparc based platforms at that time, as the Intel clown-show still looked like more work. But I do empathize with the ia64 trauma, as the roll out had a lot of collateral damage in some firms as people started jumping ship early to avoid accountability. =3
One immediate advantage that rescheduling-capable cores have that rigid compiler-based ones don’t nor ever would is that reschedules can notice patterns in execution in the current context and keep the ALU fed from well-provisioned caches even going as far as speculative execution. IA-64 and typeless or typed-at-runtime (JIT scripts, for example, like JavaScript or Python) would’ve been implemented very differently on Itanium.
I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instructio..., not EPYC https://en.wikipedia.org/wiki/Epyc.
Indeed, my point was not all chips do well with Desktop application loads.
People were bad at handling parallelism with ia64, and still have problems today on better amd platforms with less janky compilers.
The fact an $800 chip still can beat a $14000 chip at some tasks probably should tell people something about concurrency scaling overhead. =3
EPIC was Explicit Parallel Instruction Computing, the underlying engineering architecture of AI-64. Epyc is an AMD brand name.
And pivoting to concurrency on a rescheduler-intensive core as opposed to concurrency on a scheduler-based core isn’t very pertinent, particularly since we have 25 years of Moore’s Law between then and now.
"AI" responses are silly, and optimal 24 core count efficiency premise in Desktop applications offer diminishing returns on a highly concurrent 32/64/192 core Epyc line of OoO chips...
How many strings does a Bass play with in water? =3
EPIC is Explicitly Parallel Instruction Computing; nothing to do with the AMD trademark word, EPYC.
Indeed, the post does not conflate the two... look closer. =3
Itanium is yet another example of how difficult it is to fight software ecosystem momentum.
It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
Itanium 1 had hardware x86 compatibility and Itanium 2 had software x86 emulation just like Apple. It wasn't enough.
Right.
PPC was significantly faster than m68k. Intel was significantly faster again. Finally ARM was yet again.
(ARM and Intel especially on laptops)
They could pay the emulation price and still come out equal or usually on top. Even when equal there were often other benefits, like reduced heat.
As I remember hearing Itanium was a dog with x86 code. It never got fast enough to compete let alone supplant it during emulation right?
So it wasn’t (meaningfully?) faster on recompiled code or new code. It wasn’t faster on new code. But it cost way more.
Not a winning combination.
IIRC Itanium was faster on natively compiled HPC code, presumably because it had more FPUs and larger cache than the Pentium 4. But in general it probably wasn't a good upgrade and Intel would have had to sandbag x86 a lot to force Itanium adoption.
The other problem was that the Pentium 4 itself was kind of a dog, and then the Pentium M and Core lines started making that look bad, by which point the Itanic passengers could feel their socks getting wet and a growing concern about there not being enough life boats.
Only because AMD exists it wasn't enough. Had Intel been free to decide where x86 goes, the Itanium story would be much different.
Apple succeeds on their hardware transitions exactly because there isn't a clones market.
Agreed, everyone has a pet architecture that fascinates them, but if its so good only 5 people can code for the target... it is e-waste within a year.
Apple is an exception as it has always had a walled-garden ecosystem with the OS, so can force shifts in architectures unlike most companies. The M3/M4 Pro series with unified GPUs is probably the best design on the consumer market right now, but people are not leveraging it as much as they would have in other ecosystems.
Have a wonderful day =3
Apple is the survivor of another era, people keep forgetting that x86 clones are the exception of how computer market used to be, not the other way around.
The walled garden is an advantage of some sort, but they’ve also never made a bad call on switching architectures.
We don’t know what it would look like if Apple had chosen something that ended up like Itanium. It’s quite possible they don’t have the clout to pull it off.
(Maybe they should have gone Intel instead of PPC, but both were significantly better than m68k at that point)
> they’ve also never made a bad call on switching architectures.
It seems more like they have a high willingness to switch architectures.
Predicting which one is better in the year that you do it or the couple of years after isn't that hard. The question is, where is it going to be in a decade or two?
Each time they picked a huge company you wouldn't have expected to fail in that year, first IBM, then Intel. But that's the problem with huge companies, after a few years on top they tend to get complacent and stagnate.
Now Apple itself is the big company, but it remains to be seen if they're not still going to end up on e.g. RISC-V within the next ten years or so.
>We don’t know what it would look like if Apple had chosen something that ended up like Itanium
Apple made a few mistakes, but mostly by trying to compete with doomed hype markets like AR/VR.
Some also ponder what the ecosystem would look like today if the Windows NT kernel had stayed on RISC like initially planned.
The "What if __ ?" universe are fun to imagine, but ultimately less important than the "What now?" universe we live in. =3
I would already be happy if Windows NT had been more serious about UNIX compatibility.
I only bought that Linux Unleashed book in 1995's Summer, because Windows NT wasn't good enough for doing university assignments at home, which used a mix of DG/UX and Solaris on the campus.
Oh sure, Apple has TONS of mistakes if we look overall.
I was only talking about CPU transitions.
I have a funny story about a windows IA-64 box.
I was working for a large bank and it was all windows, including production. We used to run WebSphere Application Server on Windows. I was looking for a dev server to run unit tests on, including integration tests which required an actual WebSphere instance. The infrastructure team said they had “a box” going spare and it turned out to be IA64 on Windows.
If my memory serves me correctly WebSphere only ran on windows for IA-64 up to 6 and we were running on 7.
I had to do a bit of hacking but I did manage to get it working using the dlls from the 6 version. It was fine for running integration tests and a pretty fast box considering.
Am I right to guess that neither your dev nor prod machines ran IA-64? If so that's not ideal, but beggars can't be choosers & a spare box from the infra team available right now is better than getting a box built to meet your exact specs available after the usual multi-quarter internal lead time.
Superficially it sounds a little crazy, but it's probably a lot less crazy than far more mainstream antipatterns (e.g. 'lets have our CI download all the dependencies from npm over the internet each time the build runs')!
Did running the unit tests on IA-64 ever flush out genuine issues that were 'working by accident' on x86?
> If so that's not ideal
Agreed!!
I would have loved something better but sometimes you just have to make do.
WebSphere was 99% Java (except for a few pesky dlls) and I never saw any oddities, it worked the same as it did on the old x86 VM I had which was woefully under spec. Our entire software platform was on WebSphere.
It really was a meaty box, which was a huge help because the tests originally (before IA64 box) used to take all night to run.
What's even crazier is that someone vibe-coded ia64 emulation support for QEMU: https://github.com/syunnPC/qemu-system-ia64
It's interesting to see how LLMs have definitely become a force-multiplier to motivate people into doing things they wouldn't otherwise have the time and effort to.
It really depends on the end goal. For personal tools that one uses, LLMs are extremely useful. But publicly used software doesn't only need to be written - it also needs to be maintained. And considering that it's extremely easy to implement features that are not used, vibe coded software tends to be, in best case, a mixed bag, and in worst (I believe typical) case, quickly abandoned.
Vibe coded software is the modern equivalent of the shovelware of the 90s.
Vibe coded software is the modern equivalent of the shovelware of the 90s.
I don't think so, especially as the latter was attempting to make a profit but this clearly wasn't done with a for-profit motive in mind.
I have been pairing with Claude Opus and it’s quite impressive. I have explored a number of possible changes to things like VTE and the Hercules mainframe emulator.
Sweet. What changes to Hercules have you been considering? I have had a long running (and maintained!) MVS instance in Hercules for quite a few years now, just for fun.
I want a telnet port connecting directly to the Hercules console when it runs headless, as that is the way it ends up running in Docker. The Hercules console does a lot of heavy lifting that could be implemented at the terminal (as even Windows now has a proper terminal). It went as far as allowing me to connect and see the console transcript, which is pretty already.
Another thing I want that I haven't figured out is to print to my network printers - they all do lpr and ipp, but Hercules direct to socket approach didn't work for me and I need to do more research on that. Ideally, the line in the config could be a pipe command where I could turn the page into PostScript to be netcat it to the printer. or massage it through a converter that took in an IBM line printer EBCDIC stream and spat out ASCII for a "normal" printer.
Would be amazing to implement a JIT in hercules (would make it 10x faster potentially as fast as z/PDT which implements a JIT); good timing as IBM is retiring z/PDT!
In this domain and others like it especially!
It's bone crushingly dry to try and figure this kind of shit out yourself, can do everything right according to every available reference and code comment only to get compiler and linker errors nobody has ever seen or posted about. Weeks and weeks of smashing your face against a wall until it gives. Now anyone can get twice as far in an evening. And that fuckin rules
Hard to not get a little hyperbolic about it... but I can't wait for everyone to exhaust their meme projects/ports and models to get just a bit better. Feels like we're about to have something of a golden age when everyone starts really making the stuff they've always wanted.
Plus you can point it at actual software or tests with known results and tell it to keep going until it gets it.
Open Source and LLMs seem to be complementary technologies that have resulted in an absolute surge of productivity multipliers.
Recently thanks to Modern Vintage Gamer on youtube, there has been a push to see if you could get Doom to run on the NeoGeo. Because of its very unique hardware (no framebuffer) it is a very unqiue and tough task.
And yet, some folks have come to the battle and have ended up extensively using LLM's to code it. It is wild to see that these things can target such an obscure platform and get some decent results in a very short amount of time.
https://www.youtube.com/watch?v=WPxhuKTltsk
This is something that doesn't have any real economic value but many are more than happy to see happen.
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.
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?
I'm still waiting on mine, I doubt I'll ever see it though...
They are in a tough spot. They have to pick between milking their legacy clients who have been running VMS workloads and don’t want to port them to anything else, and a much more risky attempt to develop a consulting ecosystem so those clients can remain on VMS indefinitely. This ecosystem would eat into their own support business at the expense of reducing incentives to migrate to different platforms.
I'll admit that "OS snob who just wants to run VMS because they once ran it on Alpha" is pretty low on the freebie list, but they didn't even say no, they just strung me along until I gave up caring.
I really wish they released it under a GPL license. Unless an event starts an adoption uptick for greenfield projects (and it'd take some time for that). I wish they had an easy way to deploy an OpenVMS instance on a cloud service the same way IBM does with their POWER and Z machines (sadly, no Linux on POWER from them).
Huh. It looks like they're actually getting rid of their as400 hosting... I wonder what that would have cost, being the only players in the game...
> Images for the Virtual Server for VPC (s390x architecture) are deprecated. Starting 28 February 2026, you can't create new instances from s390x images. Existing instances are supported until 20 February 2027. Any instances that remain after that date are deleted.
This is much harder problem than most CPU emulators as IA-64 isn't really just another ISA. EPIC most significantly allows the RE which seems like the main implementation challenge. Does the emulator model the RSE or are there shortcuts for Windows compatibility? Also, which Windows model is booting?
The Itanic was built specifically by HP to sink Fujitsu, hitachi, nec, unisys and sgi. So in that sense it was a success.
This was my take on it: https://honeypot.net/2021/07/29/the-itanic-has.html
Key relevant quote:
> In 1994, Intel and HP looked around and saw a wide variety of successful server CPU architectures like Alpha, MIPS, SPARC, and POWER. This annoyed them and they decided to make a new CPU that no one would want to use.
True. But it’s a technological representation of all that’s wrong with the industry.
Absolutely. This monstrosity managed to have all what was wrong with CISC and all of the disadvantages of RISC at a higher price point than anything on the market at the time.
When it comes to Itanium all I can think of is how I wish I could have an Alpha. And how no one should care about Itanium.
It’s the product of companies bent on doing all the wrong things.
It took longer than necessary, but in what ways do you think an Intel Core-derived chip is different from what an “Intel Alpha” would have been?
Taking for granted that hardware backcompat (Itanium had this, too!) was a starting requirement…
Wasn't there a problem with Alpha, that it had too weak memory model or something? Think of atomic instructions with multi CPU system. Or do I remember something wrong?
Alpha was great but that wasn't enough against the convenience of just running an x86 box. It didn't find a niche quickly enough. ARM survived because they were low power. POWER survived because IBM is one big niche. MIPS died and reincarnated into RISC-V. I have no idea where Alpha would have gone had it not been dropped.
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
It would make sense to implement it in QEMU instead. There was some previous work in the past, don't have a link right now to the original patchseries, but here is the repository[1]. In theory, it could be adapted to the modern QEMU code infrastructure and APIs and be a good starting point. Back in the past I started[2] doing that but quickly dropped because had no time to finish.
EDIT: It looks like it might be this one: https://github.com/syunnPC/qemu-system-ia64
[1] https://github.com/pvaibhav/qemu-ia64
[2] https://github.com/XVilka/qemu-ia64/branches/all
HP-UX support might make a compelling retirement project for someone.
C and C++ compilers weren't great, but that HP-UX Vault was a great experience, before anyone knew what the word containers in computing world means.
For sure, I'm glad we have those emulators, real hardware is hard to find or expensive or faulty. Having emulators helps a lot.
OpenVMS ran on the Itanium also; wonder how far it could get in booting?