9 ms·

The Itanic Saga: The History of VLIW and Itanium

80 points by blakespot 3y ago

gregw2 3y ago
I’d be interested in understanding why the compilers never panned out but have never seen a good writeup on that. Or why people thought the compilers would be able to succeed in the first place at the mission.
- clausecker 3y ago
  There are a number of reasons for the Itanium's poor performance, and it's the combination of these various factors that did it in. I wasn't present back in the Itanium's heyday, but this is what I gathered. As a quick recap, superscalar processors have multiple execution units, each of which can execute one instruction each cycle. So if you have three execution units, your CPU can execute up to three instructions every cycle. The conventional way to make use of the power of more than one execution unit is to have an out-of-order design, where a complicated mechanism (Tomasulo algorithm) decodes multiple instructions in parallel, tracks their dependencies and dispatches them onto execution units as they can be executed. Dependencies are resolved by having a large physical register file, which is dynamically mapped onto the programmer-visible logical register file (register renaming). This works well, but is notoriously complex to implement and requires a couple of extra pipeline stages before decode and execution, increasing the latency of mispredicted branches. The idea of VLIW architectures was to improve on this idea by moving the decision which instruction to execute on which port to the compiler. The compiler, having prescient knowledge about what your code is going to do next, can compute the optimal assignment of instructions to execution units. Each instruction word is a pack of multiple instructions, one for each port, that are executed simultaneously (these words become very wide, hence VLIW for Very Long Instruction Word). In essence, all the bits of the out-of-order mechanism between decoding and execution ports can be done away with and the decoder is much simpler, too. However, things fail in practice: * the whole idea hinges on the compiler being able to figure out the correct instruction schedule ahead of time. While feasible for Intel's/HP's in house compiler team, the authors of other toolchains largely did not bother, instead opting for more conventional code generation that did not performed all too well. * This issue was exacerbated by the Itanium's dreadful model for fast memory loads. You see, loads can take a long time to finish, especially if cache misses or page faults occur. To fix that, the Itanium has the option to do a speculative load, which may or may not succeed at a later point. So you can do a load from a dubious pointer, then check if the pointer is fine (e.g. is it in bounds? Is it a null pointer?), and only once it has been validated you make use of the result. This allows you to hide the latency of the load, significantly speeding up typical business logic. However, the load can still fail (e.g. due to to pagefault), in which case your code has to roll back to where the load should be performed and then do a conventional load as a back-up. Understandably, few, if any compilers ever made use of this feature and load latency was dealt with rather poorly. * Relatedly, the latency of some instructions like loads and division is variable and cannot easily be predicted. So there usually isn't even the one perfect schedule the compiler could find. Turns out the schedule is much better when you leave it to the Tomasulo mechanism, which has accurate knowledge of the latency of already executing long-latency instructions. * By design, VLIW instruction sets encode a lot about how the execution units work in the instruction format. For example, Itanium is designed for a machine with three execution units and each instruction pack has up to three instructions, one for each of them. But what if you want to put more execution units into the CPU in a future iteration of the design? Well, it's not straightforward. One approach is to ship executables in a bytecode, which is only scheduled and encoded on the machine it is installed on, allowed the instruction encoding and thus number of ports to vary. Intel had chosen a different approach and instead implemented later Itanium CPUs as out-of-order designs, combining the worst of both worlds. * Due to not having register renaming, VLIW architectures conventionally have a large register file (128 registers in the case of the Itanium). This slows down context switches, further reducing performance. Out-of-order CPUs can cheat by having a comparably small programmer-visible state, with most of the state hidden in the bowels of the processor and consequently not in need of saving or restoring. * Branch prediction rapidly grew more and more accurate shortly after the Itanium's release, reducing the importance of fast recovery from mispredictions. These days, branch prediction is up to 99% accurate and out-of-order CPUs can evaluate multiple branches per cycle using speculative execution. A feature, that is not possible with a straightforward VLIW design due to the lack of register renaming. So Intel locked itself out of one of the most crucial strategies for better performance with this approach. * Another enginering issue was that x86 simulation on the Itanium performed quite poorly, giving existing customers no incentive to switch. And those that did decide to switch found that if they invest into porting their software, they might as well make it fully portable and be independent of the architecture. This is the same problem that led to the death of DEC: by forcing their customers to rewrite all the VAX software for the Alpha, the created a bunch of customers that were no longer locked into their ecosystem and could now buy whatever UNIX box was cheapest on the free market.
  - Kon-Peki 3y ago
    > To fix that, the Itanium has the option to do a speculative load, which may or may not succeed at a later point. So you can do a load from a dubious pointer, then check if the pointer is fine (e.g. is it in bounds? Is it a null pointer?), and only once it has been validated you make use of the result. Way back in the day, as a fairly young engineer, I was assigned to a project to get a bunch of legacy code migrated from Alpha to Itanium. The assignment was to "make it compile, run, and pass the tests. Do nothing else. At all." We were using the Intel C compiler on OpenVMS and every once in a while would encounter a crash in a block of code that looked something like this: if(ptr != NULL && ptr->val > 0) { //do something } else { //init the ptr } It was evaluating both parts of the if statement simultaneously and crashing on the second. Not being allowed to spend too much time debugging or investigating the compiler options, we did the following: if(ptr != NULL) { if(ptr->val > 0) { //do something } } else { //init the ptr } Which resolved the problem! EDIT - I recognize that the above change introduces a potential bug in the program ;) Obviously I wasn't copying code verbatim - it was 10-15 years ago! But you get the picture - the compiler was wonky, even the one you paid money for.
    - deleted 3y ago
      [deleted]
    - jandrese 3y ago
      When I was learning C many years ago I was warned that some compilers don't support boolean short circuiting and thus you had to be careful with it.
    - quux 3y ago
      Is this one of those rare cases where using a goto would be reasonable?
      - mjevans 3y ago
        The main case I ever found was implement missing language features. E.G. break 3; // Break 3 levels up break LABEL; // Break to a named label - safer-ish than goto goto LABEL; // When you have no other option. Usually for breaking out of a really deep set of loops to an outer loop. Such as a data stream reset, end of data, or for an error so bad a different language might E.G. throw an error and usually die.
- _chris_ 3y ago
  > I’d be interested in understanding why the compilers never panned out but have never seen a good writeup on that. Or why people thought the compilers would be able to succeed in the first place at the mission. It's a fundamentally impossible ask. Compilers are being asked to look at a program (perhaps watch it run a sample set) and guess the bias of each branch to construct a most-likely 'trace' path through the program, and then generate STATIC code for that path. But programs (and their branches) are not statically biased! So it simply doesn't work out for general-purpose codes. However, programs are fairly predictable, which means a branch predictor can dynamically learn the program path and regurgitate it on command. And if the program changes phases, the branch predictor can re-learn the new program path very quickly. Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work.
  - yvdriess 3y ago
    > Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work. RIP Transmeta
    - andromeduck 3y ago
      Transmeta lived on in Nvidia's Project Denver but Denver was optimized for x86 and the Intel settlement precluded that. It ended up being too buggy/inefficient to compete in the market and effectively abandoned after the second generation.
  - gregw2 3y ago
    This makes a lot of sense to me, thanks for boiling it down. Compilers can predict the code instructions coming up decently, but not really the data coming up, so VLIW doesn't work that well compared to branch prediction and speculative and out of order execution complexities which VLIW tried to simplify away on branching-heavy commercial/database server workloads. Does that sound right?
  - actionfromafar 3y ago
    I think it could have worked if the IDE had performance instrumentation (some kind of tracing) which would have been fed in to the next build. (And perhaps several iterations of this.) Another way to leverage the Itanium power would have been to make a Java Virtual Machine go really fast, with dynamic binary translation. This way you'd sidestep all the C UB optimization caveats.
- dfox 3y ago
  One big reason is that it was 20 years ago. At that time, gcc only did rudimentary data flow analysis and full SSA dataflow was at best an experimental feature. Also, the market would not really accept a C compiler that does the kind of agressive UB exploitation needed to extract the paralelism from C code (and instead people mostly tended to pass -Wno-strict-aliasing and friends in order to reduce "warning noise"). This issue is somewhat C specific and Fortran compilers produced decidedly better IA-64 code than C compilers. Which is what together with respectable FP performance of Itanium made it somewhat popular for HPC.
cpr 3y ago
Was at Multiflow (Yale spinoff with Josh Fisher and John O'Donnell) '85-90 and saw the VLIW problem up close (was in the OS group, eventually running it). The main problem was compiler complexity -- the hoped-for "junk parallelism" gains really never panned out (maybe 2-3X?), so the compiler was best when it could discover, or be fed, vector operations. But Convex (main competitor at the time) already had the "minisupercomputer vector" market locked up. So Multiflow folded in early '90 (I had already bailed, seeing the handwriting mural) after burning through $60M in VC, which was a record at the time, I believe.
- OhMeadhbh 3y ago
  And hilariously*, Convex was eventually eaten by HP. Though the PowerPC Altivec/Velocity engine always looked a lot like Parsec to me. The past lives on in weird places. [*] And by "hilariously," I mean "painfully."
  - mkhnews 3y ago
    Was at Convex and then HP (and then Convey) and worked quite hard porting/optimizing numerical/scientific apps for the I2. Eventually, I think performance for some apps was ok, I mean considering a 900 Mhz clock and all.
- pavlov 3y ago
  Funny how today burning through that amount is entirely ordinary and expected for most startups working on much more trivial problems. Just the other day it was reported that Brex, an expense management SaaS, has a $17M / month burn rate. That’s almost $60M in one quarter.
  - raverbashing 3y ago
    "Expected" I think people are just going happy-go-click-click in AWS panel and not auditing it correctly (And if AWS would release aws left-pad I'm sure some people would pay for it)
    - 3y ago
quic_bcain 3y ago
A modern history of VLIW should also include mention the Hexagon FSP architecture used by Qualcomm in its SoCs. With a smaller target market it's probably more sustainable than Itanium was. Disclaimer: Qualcomm employee working on hexagon toolchain.
- chasil 3y ago
  Sophie Wilson also mentions Firepath in several of her YouTube lectures.
- p_l 3y ago
  Also, GPU VLIW architectures (including GCN and it's successors CDNA and RDNA) and yes, various coprocessors. Once heard comparison that Itanium was pretty good for a fast DSP, but too expensive XD
  - MindSpunk 3y ago
    GCN is not VLIW (follows that neither is RDNA and derivatives). You're thinking of TeraScale, the generation before GCN, which was VLIW.
    - p_l 3y ago
      My bad - I misread a doc recently which implied otherwise, albeit that GCN used shorter ones. Just checked AMD docs straight and it was indeed normal scalar instructions. AIE and AIE-ML from AMD do use VLIW btw
ghaff 3y ago
I actually have a short book on the Itanic/Itanium done and planned to have it released as a free download by now. But various schedule-related stuff happened and it just hasn't happened yet. I was a mostly hardware-focused industry analyst during Itanium's heyday so I find the topic really interesting. From a technical perspective, compilers (and dependency on them) certainly played a role but there were a bunch of other lessons too around market timing, partner strategies, fighting the last war, etc.
- BirAdam 3y ago
  Do it, do it, do it!
  - ghaff 3y ago
    I will but I want to use it as part of a website relaunch and, for various reasons, the appropriate timing of that relaunch slipped out.
- deleted 3y ago
  [deleted]
- demondemidi 3y ago
  I worked on Merced post-silicon, and McKinley presilicon. I wasn't an architect on the project, I just worked on keeping the power grid alive and thermals under control. It reminded me of working on the 486: the team was small and engaged, even though HP was problematic for parts of it. Pentium Pro was sucking up all the marketing air, so we were kind of left alone to do our own thing since the part wasn't making money yet. This was also during the corporate wide transition to Linux, removing AIX/SunOS/HPUX. I had a Merced in my office but sadly it was running linux in 32-bit compatibility mode, which is where we spent a lot of time fixing bugs because we knew lots of people weren't going to port to IA64 right away, and that ate up a ton of debug resources. The world was still migrating to Windows NT 3.5 and Windows 95, so migrating to 64 bit was way too soon. I don't remember when the linux kernel finally ported to IA64, but it seemed odd to have a platform without an OS (or an OS running in 32-bit mode). We had plenty of emulators, there's no reason why pre-silicon kernel development couldn't have happened faster (which was what HP was supposed to be doing). Kind of a bummer but it was a fun time, before the race to 1 GHz became the next $$$ sink / pissing contest.
bee_rider 3y ago
When will compilers be good enough to take another swing at VLIW?
- gumby 3y ago
  Now, but temporally rather than spatially. A VLIW has a lot of functional units that are used simultaneously.* Modern processors (out of order, superscalar, using speculative execution, pick your techniques and buzzwords) allow these units to be used simultaneously and dynamically depending on the instruction mix. With VLIW some instruction units won’t be used and so won’t contribute to performance. The compilers can give hints to the execution CPU but it also decides what to do when. With VLIW (EPIC is probably a better name in this regard) you have to guess right up front, without knowing what the data will be. * So does SIMD, but in VLIW you don’t have to have a single instruction.
- drivebycomment 3y ago
  Approximately never for non-HPC code.
- p_l 3y ago
  VLIW is pretty well represented in the TOP500 supercomputers and in various other performance niches. What isn't is not so much VLIW as EPIC - the explicit parallelism of Itanium, which among others didn't really support out of order or branch prediction in ways other than compiler code generator. High levels of SMT (sometimes with just a barrel execution models) are used in GPUs to smooth out the performance characteristics involved, from my understanding.
mjevans 3y ago
VLIW reminded me of Transmeta, but unfortunately... "For Sun, however, their VLIW project was abandoned. David Ditzel left Sun and founded Transmeta along with Bob Cmelik, Colin Hunter, Ed Kelly, Doug Laird, Malcolm Wing and Greg Zyner in 1995. Their new company was focused on VLIW chips, but that company is a story for another day."
DeathArrow 3y ago
Is there a way for VLIW to succeed in generic computing? Or is impossible?
- Findecanor 3y ago
  Mill Computing thinks so, with their "The Mill" architecture. Its proponents have sometimes described it as "Itanium done right". The Mill uses a variable length encoding at the bit level. They also avoid encoding destination registers. This alleviates one large drawback of VLIW: code density. Itanium itself has ~42-bit instructions: combined with EPIC, even highly optimised, the code density was often less than half that of contemporary RISC architectures. Many Mill instructions are 16-24 bits wide. Mill programs are also supposed to be distributed in an intermediate format (think LLVM-IR, WebAssembly or ANDF), to be compiled at install-time. This is supposed to decouple the platform in the long run from the actual instruction set on that particular CPU, allowing the instruction encoding to change between models. However, Mill Computing has worked on their design for many years now without any product announcements. Many are afraid that its patents will expire or be sold before they get anything released. What I personally like most about the architecture is not the promised performance but features for program security and microkernels.
chx 3y ago
> These delays didn’t stop the hypetrain. This is an understatement. From an older article "How the Itanium killed the Computer Industry" https://www.pcmag.com/archive/how-the-itanium-killed-the-computer-industry-236394 https://www.pcmag.com/archive/how-the-itanium-killed-the-com... > In 1997 Intel was the king of the hill; in that year it first announced the Itanium or IA-64 processor. That same year, research company IDC predicted that the Itanium would take over the world, racking up $38 billion in sales in 2001. > What we heard was that HP, IBM, Dell, and even Sun Microsystems would use these chips and discontinue anything else they were developing. This included Sun making noise about dropping the SPARC chip for this thing—sight unseen. I say "sight unseen" because it would be years before the chip was even prototyped. The entire industry just took Intel at its word that Itanium would work as advertised in a PowerPoint presentation. And then the original article has an Intel leader saying "Everything was new. When you do that, you're going to stumble". Yeah, much as Intel stumbled with the Pentium IV and basically everything since Skylake in 2015 (which was late). Let's emphasize this: for near ten years now, Intel can't deliver on time and on target. Just last year, Sapphire Rapids after being late by two years shipped in 2023 March and needed to pause in June because of a bug. Meteor Lake was also two years late. In 2020 https://www.zdnet.com/article/intels-7nm-product-transition-delayed-focus-shifted-to-10nm/ https://www.zdnet.com/article/intels-7nm-product-transition-... > Intel's first 7nm product, a client CPU, is now expected to start shipping in late 2022 or early 2023, CEO Bob Swan said on a conference call Thursday. > The yield of Intel's 7nm process is now trending approximately 12 months behind the company's internal target. Well then the internal target must've been late 2021 and it came out late 2023.
flakiness 3y ago
VLIW is everywhere in client side ML accelerator space for some reason. Another comment mentioned Snapdragon's Hexagon, which they try to rebrand as NPU with some Mat-mul circuits. Intel Core's NPU, which is based on Movidius VPU, also has a VLIW based core in it. It is called SHAVE. And AMD's XDNA NPU, which is based on Xilinx Alveo, also has a VLIW based core they call AI-Engine.
Findecanor 3y ago
"Something of a tragedy: the Itanium was Bob Rau's design, and he died before he had a chance to do it right. His original efforts wound up being taken over for commercial reasons and changed into a machine that was rather different than what he had originally intended and the result was the Itanium. While it was his machine in many ways, it did not reflect his vision." Quote from Ivan Goddard of Mill Computing: https://www.youtube.com/watch?v=JS5hCjueqQ0&t=4054s https://www.youtube.com/watch?v=JS5hCjueqQ0&t=4054s Bob Rau: https://en.wikipedia.org/wiki/Bob_Rau https://en.wikipedia.org/wiki/Bob_Rau
lastgeniusua 3y ago
the total lack of sources and references (other than to the articles on this very blog) is annoying to say the least. is there anything at all to read on this alleged Elbrus influence on Itanium plans, in Russian or English?
dsand 3y ago
HP partnered with Intel to bring HP's Playdoh vliw architecture to market, because HP could not afford to continue investing in new leading-edge fabs. Compaq/DEC similarly killed Alpha shortly before getting acquired by HP, because Compaq could not afford its own new leading edge fab either. SGI spun off its MIPS division and switched to Itanium for the same reason -- fabs were getting too expensive for low-volume parts. The business attraction wasn't Itanium's novel architecture. It was the prospect of using the high-volume most profitable fab lines in the world. But ironically, Itanium never worked well enough to sell in enough volumes to pay its way in either fab investments or in design teams. The entire Itanium saga was based on the theory that dynamic instruction scheduling via OOO hardware could not be scaled up to high IPC with high clock rates. Lots of academic papers said so. VLIW was sold as a path to get high IPC with short pipelines and fast cycle times and less circuit area. But Intel's own x86 designers then showed that OOO would indeed work well in practice, better than the papers said. It just took huge design teams and very high circuit density, which the x86 product line could afford. That success doomed the Itanium product line, all by itself. Intel did not want its future to lie with an extended x86 architecture shared with AMD. It wanted a monopoly. It wanted a proprietary, patented, complicated architecture that no one could copy, or even retarget its software. That x86-successor arch could not be yet another RISC, because those programs are too easy to retarget to another assembler language. So, way beyond RISC, and every extra gimmick like rotating register files was a good thing, not a hindrance to clock speeds and pipelines and compilers. HP's Playdoh architecture came from its HP Labs, as had the very successful PARISC before it. But the people involved were all different. And they could make their own reputations only by doing something very different from PARISC. They sold HP management on this adventure without proving that it would work for business and other nonnumerical workloads. VLIW had worked brilliantly in numerical applications like Floating Point Systems' vector coprocessor. Very long loop counts, very predictable latencies, and all software written by a very few people. VLIW continues to thrive today in the DSP units inside all cell phone SOCs. Josh Fisher thought his compiler techniques could extract reliable instruction-level parallelism from normal software with short-running loops, dynamically-changing branch probabilities, and unpredictable cache misses. Fisher was wrong. OOO was the technically best answer to all that, and upward compatible with massive amounts of existing software. Intel planned to reserve the high-margin 64-bit server market for Itanium, so it deliberately held back its x86 team from going to market with their completed 64 bit extensions. AMD did not hold back, so Intel lost control of the market it intended for Itanium. Itanium chips were targeted only for high-end systems needing lots of ILP concurrency. There was no economic way to make chips with less ILP (or much more ILP), so no Itanium chips cheap and low-power enough to be packaged as development boxes for individual open-source programmers like Torvalds. This was only going to market via top-down corporate edicts, not bottom-up improvements. The first-gen Itanium chip, Merced, included a modest processor for directly executing x86 32-bit code. This ran much slower than Intel's contemporary cheap x86 chips, so no one wanted that migration route. It also ran slower than using static translation from x86 assembler code to Itanium native code. So HP dropped that x86 portion from future Itanium chips. Itanium had to make it on its own via its own native-built software. The large base of x86 software was of no help. In contrast, DEC designed Alpha and migration tools so that Alpha could efficiently run VAX object code at higher speeds than on any VAX.

80 points by blakespot 3y ago

I’d be interested in understanding why the compilers never panned out but have never seen a good writeup on that. Or why people thought the compilers would be able to succeed in the first place at the mission.

clausecker 3y ago
There are a number of reasons for the Itanium's poor performance, and it's the combination of these various factors that did it in. I wasn't present back in the Itanium's heyday, but this is what I gathered. As a quick recap, superscalar processors have multiple execution units, each of which can execute one instruction each cycle. So if you have three execution units, your CPU can execute up to three instructions every cycle. The conventional way to make use of the power of more than one execution unit is to have an out-of-order design, where a complicated mechanism (Tomasulo algorithm) decodes multiple instructions in parallel, tracks their dependencies and dispatches them onto execution units as they can be executed. Dependencies are resolved by having a large physical register file, which is dynamically mapped onto the programmer-visible logical register file (register renaming). This works well, but is notoriously complex to implement and requires a couple of extra pipeline stages before decode and execution, increasing the latency of mispredicted branches. The idea of VLIW architectures was to improve on this idea by moving the decision which instruction to execute on which port to the compiler. The compiler, having prescient knowledge about what your code is going to do next, can compute the optimal assignment of instructions to execution units. Each instruction word is a pack of multiple instructions, one for each port, that are executed simultaneously (these words become very wide, hence VLIW for Very Long Instruction Word). In essence, all the bits of the out-of-order mechanism between decoding and execution ports can be done away with and the decoder is much simpler, too. However, things fail in practice: * the whole idea hinges on the compiler being able to figure out the correct instruction schedule ahead of time. While feasible for Intel's/HP's in house compiler team, the authors of other toolchains largely did not bother, instead opting for more conventional code generation that did not performed all too well. * This issue was exacerbated by the Itanium's dreadful model for fast memory loads. You see, loads can take a long time to finish, especially if cache misses or page faults occur. To fix that, the Itanium has the option to do a speculative load, which may or may not succeed at a later point. So you can do a load from a dubious pointer, then check if the pointer is fine (e.g. is it in bounds? Is it a null pointer?), and only once it has been validated you make use of the result. This allows you to hide the latency of the load, significantly speeding up typical business logic. However, the load can still fail (e.g. due to to pagefault), in which case your code has to roll back to where the load should be performed and then do a conventional load as a back-up. Understandably, few, if any compilers ever made use of this feature and load latency was dealt with rather poorly. * Relatedly, the latency of some instructions like loads and division is variable and cannot easily be predicted. So there usually isn't even the one perfect schedule the compiler could find. Turns out the schedule is much better when you leave it to the Tomasulo mechanism, which has accurate knowledge of the latency of already executing long-latency instructions. * By design, VLIW instruction sets encode a lot about how the execution units work in the instruction format. For example, Itanium is designed for a machine with three execution units and each instruction pack has up to three instructions, one for each of them. But what if you want to put more execution units into the CPU in a future iteration of the design? Well, it's not straightforward. One approach is to ship executables in a bytecode, which is only scheduled and encoded on the machine it is installed on, allowed the instruction encoding and thus number of ports to vary. Intel had chosen a different approach and instead implemented later Itanium CPUs as out-of-order designs, combining the worst of both worlds. * Due to not having register renaming, VLIW architectures conventionally have a large register file (128 registers in the case of the Itanium). This slows down context switches, further reducing performance. Out-of-order CPUs can cheat by having a comparably small programmer-visible state, with most of the state hidden in the bowels of the processor and consequently not in need of saving or restoring. * Branch prediction rapidly grew more and more accurate shortly after the Itanium's release, reducing the importance of fast recovery from mispredictions. These days, branch prediction is up to 99% accurate and out-of-order CPUs can evaluate multiple branches per cycle using speculative execution. A feature, that is not possible with a straightforward VLIW design due to the lack of register renaming. So Intel locked itself out of one of the most crucial strategies for better performance with this approach. * Another enginering issue was that x86 simulation on the Itanium performed quite poorly, giving existing customers no incentive to switch. And those that did decide to switch found that if they invest into porting their software, they might as well make it fully portable and be independent of the architecture. This is the same problem that led to the death of DEC: by forcing their customers to rewrite all the VAX software for the Alpha, the created a bunch of customers that were no longer locked into their ecosystem and could now buy whatever UNIX box was cheapest on the free market.
- Kon-Peki 3y ago
  > To fix that, the Itanium has the option to do a speculative load, which may or may not succeed at a later point. So you can do a load from a dubious pointer, then check if the pointer is fine (e.g. is it in bounds? Is it a null pointer?), and only once it has been validated you make use of the result. Way back in the day, as a fairly young engineer, I was assigned to a project to get a bunch of legacy code migrated from Alpha to Itanium. The assignment was to "make it compile, run, and pass the tests. Do nothing else. At all." We were using the Intel C compiler on OpenVMS and every once in a while would encounter a crash in a block of code that looked something like this: if(ptr != NULL && ptr->val > 0) { //do something } else { //init the ptr } It was evaluating both parts of the if statement simultaneously and crashing on the second. Not being allowed to spend too much time debugging or investigating the compiler options, we did the following: if(ptr != NULL) { if(ptr->val > 0) { //do something } } else { //init the ptr } Which resolved the problem! EDIT - I recognize that the above change introduces a potential bug in the program ;) Obviously I wasn't copying code verbatim - it was 10-15 years ago! But you get the picture - the compiler was wonky, even the one you paid money for.
  - deleted 3y ago
    [deleted]
  - jandrese 3y ago
    When I was learning C many years ago I was warned that some compilers don't support boolean short circuiting and thus you had to be careful with it.
  - quux 3y ago
    Is this one of those rare cases where using a goto would be reasonable?
    - mjevans 3y ago
      The main case I ever found was implement missing language features. E.G. break 3; // Break 3 levels up break LABEL; // Break to a named label - safer-ish than goto goto LABEL; // When you have no other option. Usually for breaking out of a really deep set of loops to an outer loop. Such as a data stream reset, end of data, or for an error so bad a different language might E.G. throw an error and usually die.
_chris_ 3y ago
> I’d be interested in understanding why the compilers never panned out but have never seen a good writeup on that. Or why people thought the compilers would be able to succeed in the first place at the mission. It's a fundamentally impossible ask. Compilers are being asked to look at a program (perhaps watch it run a sample set) and guess the bias of each branch to construct a most-likely 'trace' path through the program, and then generate STATIC code for that path. But programs (and their branches) are not statically biased! So it simply doesn't work out for general-purpose codes. However, programs are fairly predictable, which means a branch predictor can dynamically learn the program path and regurgitate it on command. And if the program changes phases, the branch predictor can re-learn the new program path very quickly. Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work.
- yvdriess 3y ago
  > Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work. RIP Transmeta
  - andromeduck 3y ago
    Transmeta lived on in Nvidia's Project Denver but Denver was optimized for x86 and the Intel settlement precluded that. It ended up being too buggy/inefficient to compete in the market and effectively abandoned after the second generation.
- gregw2 3y ago
  This makes a lot of sense to me, thanks for boiling it down. Compilers can predict the code instructions coming up decently, but not really the data coming up, so VLIW doesn't work that well compared to branch prediction and speculative and out of order execution complexities which VLIW tried to simplify away on branching-heavy commercial/database server workloads. Does that sound right?
- actionfromafar 3y ago
  I think it could have worked if the IDE had performance instrumentation (some kind of tracing) which would have been fed in to the next build. (And perhaps several iterations of this.) Another way to leverage the Itanium power would have been to make a Java Virtual Machine go really fast, with dynamic binary translation. This way you'd sidestep all the C UB optimization caveats.
dfox 3y ago
One big reason is that it was 20 years ago. At that time, gcc only did rudimentary data flow analysis and full SSA dataflow was at best an experimental feature. Also, the market would not really accept a C compiler that does the kind of agressive UB exploitation needed to extract the paralelism from C code (and instead people mostly tended to pass -Wno-strict-aliasing and friends in order to reduce "warning noise"). This issue is somewhat C specific and Fortran compilers produced decidedly better IA-64 code than C compilers. Which is what together with respectable FP performance of Itanium made it somewhat popular for HPC.

cpr 3y ago

Was at Multiflow (Yale spinoff with Josh Fisher and John O'Donnell) '85-90 and saw the VLIW problem up close (was in the OS group, eventually running it). The main problem was compiler complexity -- the hoped-for "junk parallelism" gains really never panned out (maybe 2-3X?), so the compiler was best when it could discover, or be fed, vector operations. But Convex (main competitor at the time) already had the "minisupercomputer vector" market locked up. So Multiflow folded in early '90 (I had already bailed, seeing the handwriting mural) after burning through $60M in VC, which was a record at the time, I believe.

OhMeadhbh 3y ago
And hilariously*, Convex was eventually eaten by HP. Though the PowerPC Altivec/Velocity engine always looked a lot like Parsec to me. The past lives on in weird places. [*] And by "hilariously," I mean "painfully."
- mkhnews 3y ago
  Was at Convex and then HP (and then Convey) and worked quite hard porting/optimizing numerical/scientific apps for the I2. Eventually, I think performance for some apps was ok, I mean considering a 900 Mhz clock and all.
pavlov 3y ago
Funny how today burning through that amount is entirely ordinary and expected for most startups working on much more trivial problems. Just the other day it was reported that Brex, an expense management SaaS, has a $17M / month burn rate. That’s almost $60M in one quarter.
- raverbashing 3y ago
  "Expected" I think people are just going happy-go-click-click in AWS panel and not auditing it correctly (And if AWS would release aws left-pad I'm sure some people would pay for it)
  - 3y ago

quic_bcain 3y ago

A modern history of VLIW should also include mention the Hexagon FSP architecture used by Qualcomm in its SoCs. With a smaller target market it's probably more sustainable than Itanium was. Disclaimer: Qualcomm employee working on hexagon toolchain.

chasil 3y ago
Sophie Wilson also mentions Firepath in several of her YouTube lectures.
p_l 3y ago
Also, GPU VLIW architectures (including GCN and it's successors CDNA and RDNA) and yes, various coprocessors. Once heard comparison that Itanium was pretty good for a fast DSP, but too expensive XD
- MindSpunk 3y ago
  GCN is not VLIW (follows that neither is RDNA and derivatives). You're thinking of TeraScale, the generation before GCN, which was VLIW.
  - p_l 3y ago
    My bad - I misread a doc recently which implied otherwise, albeit that GCN used shorter ones. Just checked AMD docs straight and it was indeed normal scalar instructions. AIE and AIE-ML from AMD do use VLIW btw

ghaff 3y ago

I actually have a short book on the Itanic/Itanium done and planned to have it released as a free download by now. But various schedule-related stuff happened and it just hasn't happened yet. I was a mostly hardware-focused industry analyst during Itanium's heyday so I find the topic really interesting. From a technical perspective, compilers (and dependency on them) certainly played a role but there were a bunch of other lessons too around market timing, partner strategies, fighting the last war, etc.

BirAdam 3y ago
Do it, do it, do it!
- ghaff 3y ago
  I will but I want to use it as part of a website relaunch and, for various reasons, the appropriate timing of that relaunch slipped out.
deleted 3y ago
[deleted]
demondemidi 3y ago
I worked on Merced post-silicon, and McKinley presilicon. I wasn't an architect on the project, I just worked on keeping the power grid alive and thermals under control. It reminded me of working on the 486: the team was small and engaged, even though HP was problematic for parts of it. Pentium Pro was sucking up all the marketing air, so we were kind of left alone to do our own thing since the part wasn't making money yet. This was also during the corporate wide transition to Linux, removing AIX/SunOS/HPUX. I had a Merced in my office but sadly it was running linux in 32-bit compatibility mode, which is where we spent a lot of time fixing bugs because we knew lots of people weren't going to port to IA64 right away, and that ate up a ton of debug resources. The world was still migrating to Windows NT 3.5 and Windows 95, so migrating to 64 bit was way too soon. I don't remember when the linux kernel finally ported to IA64, but it seemed odd to have a platform without an OS (or an OS running in 32-bit mode). We had plenty of emulators, there's no reason why pre-silicon kernel development couldn't have happened faster (which was what HP was supposed to be doing). Kind of a bummer but it was a fun time, before the race to 1 GHz became the next $$$ sink / pissing contest.

bee_rider 3y ago

When will compilers be good enough to take another swing at VLIW?

gumby 3y ago
Now, but temporally rather than spatially. A VLIW has a lot of functional units that are used simultaneously.* Modern processors (out of order, superscalar, using speculative execution, pick your techniques and buzzwords) allow these units to be used simultaneously and dynamically depending on the instruction mix. With VLIW some instruction units won’t be used and so won’t contribute to performance. The compilers can give hints to the execution CPU but it also decides what to do when. With VLIW (EPIC is probably a better name in this regard) you have to guess right up front, without knowing what the data will be. * So does SIMD, but in VLIW you don’t have to have a single instruction.
drivebycomment 3y ago
Approximately never for non-HPC code.
p_l 3y ago
VLIW is pretty well represented in the TOP500 supercomputers and in various other performance niches. What isn't is not so much VLIW as EPIC - the explicit parallelism of Itanium, which among others didn't really support out of order or branch prediction in ways other than compiler code generator. High levels of SMT (sometimes with just a barrel execution models) are used in GPUs to smooth out the performance characteristics involved, from my understanding.

mjevans 3y ago

VLIW reminded me of Transmeta, but unfortunately... "For Sun, however, their VLIW project was abandoned. David Ditzel left Sun and founded Transmeta along with Bob Cmelik, Colin Hunter, Ed Kelly, Doug Laird, Malcolm Wing and Greg Zyner in 1995. Their new company was focused on VLIW chips, but that company is a story for another day."

DeathArrow 3y ago

Is there a way for VLIW to succeed in generic computing? Or is impossible?

Findecanor 3y ago
Mill Computing thinks so, with their "The Mill" architecture. Its proponents have sometimes described it as "Itanium done right". The Mill uses a variable length encoding at the bit level. They also avoid encoding destination registers. This alleviates one large drawback of VLIW: code density. Itanium itself has ~42-bit instructions: combined with EPIC, even highly optimised, the code density was often less than half that of contemporary RISC architectures. Many Mill instructions are 16-24 bits wide. Mill programs are also supposed to be distributed in an intermediate format (think LLVM-IR, WebAssembly or ANDF), to be compiled at install-time. This is supposed to decouple the platform in the long run from the actual instruction set on that particular CPU, allowing the instruction encoding to change between models. However, Mill Computing has worked on their design for many years now without any product announcements. Many are afraid that its patents will expire or be sold before they get anything released. What I personally like most about the architecture is not the promised performance but features for program security and microkernels.

chx 3y ago

> These delays didn’t stop the hypetrain. This is an understatement. From an older article "How the Itanium killed the Computer Industry" https://www.pcmag.com/archive/how-the-itanium-killed-the-computer-industry-236394 https://www.pcmag.com/archive/how-the-itanium-killed-the-com... > In 1997 Intel was the king of the hill; in that year it first announced the Itanium or IA-64 processor. That same year, research company IDC predicted that the Itanium would take over the world, racking up $38 billion in sales in 2001. > What we heard was that HP, IBM, Dell, and even Sun Microsystems would use these chips and discontinue anything else they were developing. This included Sun making noise about dropping the SPARC chip for this thing—sight unseen. I say "sight unseen" because it would be years before the chip was even prototyped. The entire industry just took Intel at its word that Itanium would work as advertised in a PowerPoint presentation. And then the original article has an Intel leader saying "Everything was new. When you do that, you're going to stumble". Yeah, much as Intel stumbled with the Pentium IV and basically everything since Skylake in 2015 (which was late). Let's emphasize this: for near ten years now, Intel can't deliver on time and on target. Just last year, Sapphire Rapids after being late by two years shipped in 2023 March and needed to pause in June because of a bug. Meteor Lake was also two years late. In 2020 https://www.zdnet.com/article/intels-7nm-product-transition-delayed-focus-shifted-to-10nm/ https://www.zdnet.com/article/intels-7nm-product-transition-... > Intel's first 7nm product, a client CPU, is now expected to start shipping in late 2022 or early 2023, CEO Bob Swan said on a conference call Thursday. > The yield of Intel's 7nm process is now trending approximately 12 months behind the company's internal target. Well then the internal target must've been late 2021 and it came out late 2023.

flakiness 3y ago

VLIW is everywhere in client side ML accelerator space for some reason. Another comment mentioned Snapdragon's Hexagon, which they try to rebrand as NPU with some Mat-mul circuits. Intel Core's NPU, which is based on Movidius VPU, also has a VLIW based core in it. It is called SHAVE. And AMD's XDNA NPU, which is based on Xilinx Alveo, also has a VLIW based core they call AI-Engine.

Findecanor 3y ago

"Something of a tragedy: the Itanium was Bob Rau's design, and he died before he had a chance to do it right. His original efforts wound up being taken over for commercial reasons and changed into a machine that was rather different than what he had originally intended and the result was the Itanium. While it was his machine in many ways, it did not reflect his vision." Quote from Ivan Goddard of Mill Computing: https://www.youtube.com/watch?v=JS5hCjueqQ0&t=4054s https://www.youtube.com/watch?v=JS5hCjueqQ0&t=4054s Bob Rau: https://en.wikipedia.org/wiki/Bob_Rau https://en.wikipedia.org/wiki/Bob_Rau

lastgeniusua 3y ago

the total lack of sources and references (other than to the articles on this very blog) is annoying to say the least. is there anything at all to read on this alleged Elbrus influence on Itanium plans, in Russian or English?

dsand 3y ago

HP partnered with Intel to bring HP's Playdoh vliw architecture to market, because HP could not afford to continue investing in new leading-edge fabs. Compaq/DEC similarly killed Alpha shortly before getting acquired by HP, because Compaq could not afford its own new leading edge fab either. SGI spun off its MIPS division and switched to Itanium for the same reason -- fabs were getting too expensive for low-volume parts. The business attraction wasn't Itanium's novel architecture. It was the prospect of using the high-volume most profitable fab lines in the world. But ironically, Itanium never worked well enough to sell in enough volumes to pay its way in either fab investments or in design teams. The entire Itanium saga was based on the theory that dynamic instruction scheduling via OOO hardware could not be scaled up to high IPC with high clock rates. Lots of academic papers said so. VLIW was sold as a path to get high IPC with short pipelines and fast cycle times and less circuit area. But Intel's own x86 designers then showed that OOO would indeed work well in practice, better than the papers said. It just took huge design teams and very high circuit density, which the x86 product line could afford. That success doomed the Itanium product line, all by itself. Intel did not want its future to lie with an extended x86 architecture shared with AMD. It wanted a monopoly. It wanted a proprietary, patented, complicated architecture that no one could copy, or even retarget its software. That x86-successor arch could not be yet another RISC, because those programs are too easy to retarget to another assembler language. So, way beyond RISC, and every extra gimmick like rotating register files was a good thing, not a hindrance to clock speeds and pipelines and compilers. HP's Playdoh architecture came from its HP Labs, as had the very successful PARISC before it. But the people involved were all different. And they could make their own reputations only by doing something very different from PARISC. They sold HP management on this adventure without proving that it would work for business and other nonnumerical workloads. VLIW had worked brilliantly in numerical applications like Floating Point Systems' vector coprocessor. Very long loop counts, very predictable latencies, and all software written by a very few people. VLIW continues to thrive today in the DSP units inside all cell phone SOCs. Josh Fisher thought his compiler techniques could extract reliable instruction-level parallelism from normal software with short-running loops, dynamically-changing branch probabilities, and unpredictable cache misses. Fisher was wrong. OOO was the technically best answer to all that, and upward compatible with massive amounts of existing software. Intel planned to reserve the high-margin 64-bit server market for Itanium, so it deliberately held back its x86 team from going to market with their completed 64 bit extensions. AMD did not hold back, so Intel lost control of the market it intended for Itanium. Itanium chips were targeted only for high-end systems needing lots of ILP concurrency. There was no economic way to make chips with less ILP (or much more ILP), so no Itanium chips cheap and low-power enough to be packaged as development boxes for individual open-source programmers like Torvalds. This was only going to market via top-down corporate edicts, not bottom-up improvements. The first-gen Itanium chip, Merced, included a modest processor for directly executing x86 32-bit code. This ran much slower than Intel's contemporary cheap x86 chips, so no one wanted that migration route. It also ran slower than using static translation from x86 assembler code to Itanium native code. So HP dropped that x86 portion from future Itanium chips. Itanium had to make it on its own via its own native-built software. The large base of x86 software was of no help. In contrast, DEC designed Alpha and migration tools so that Alpha could efficiently run VAX object code at higher speeds than on any VAX.