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
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.
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...
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
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...
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)
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, 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.
You can, in the same way that you can manually manage reservation station port residency as a programmer in an OoO core to get maximum throughput, but neither of those are required in normal programming.
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.
1) Yes, unless you add abstraction at the ABI/ISA level in hardware or microcode, which then defeats the point of VLIW to some extent. I mention this in my comment; Itanium in particular was hamstrung by trying to patch over this. This is one of the "sliders" you're dragging with VLIW; trading floor plan for cross compatibility.
2) Well, kind of, but this is just the Mythical Compiler I discussed in my own parent comment, regardless of language, and I find this argument tangental to the core issue. Yes, C makes things bad by encouraging both aliasing and pointer-chasing, but one can also argue that a sufficiently advanced compiler can discover the intra-program hazards and prefetch accordingly (see monocasa's discussion); this is moving where the parallelism is expressed, but isn't patching the fundamental issue.
Overall, I don't think the issue is that nobody will build a language or compiler for an architecture with compatibility problems. We see good compilers and lots of language research in this space for DSP and AI workloads. I still believe that the fundamental issue is that VLIW is not suited for general purpose computing workloads due to cache residency issues caused by context switching.
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.
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
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)
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 was only talking about CPU transitions.
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.
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.
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.
Apple succeeds on their hardware transitions exactly because there isn't a clones market.