3 ms·

>"The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructions in a given word can be executed at once.

>"The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructions in a given word can be executed at once. I believe you are describing VLIW architecture here? Is that correct? >"This removes the need for the hardware to do reordering, and shoves the responsibility for finding parallelism onto the human or compiler, both of which can, presumably, take a more global view of the problem than a piece of silicon can." Interesting. How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW? I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

leeter 4y ago
> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? The answer is: yes Itanium failed because getting instruction parallelism is actually incredibly hard to do and compilers didn't catch up in time to make it matter. But it also failed because of AMD64 which had backwards compat, was cheaper by a lot, and was a lot easier to get decent perf out of. Opinion: I think Itanium was always destined to fail. The idea seems good on paper but fails in practicality because it limits what the hardware can do to achieve speed without breaking backwards compat with itself. You can't have a superscalar Itanium by definition because branch prediction etc. is by design delegated to the compiler. This means that the chips can literally only go up via clock speed, which as we now know doesn't scale forever.
- Animats 4y ago
  > and compilers didn't catch up in time to make it matter. Yes. I once saw am EE380 talk at Stanford by the HP team working on the Itanium compiler. They had to solve a complicated minimization problem for each block of instructions. It wasn't going well. Branch prediction decisions have to be made at compile time. Intel has built compilers where you feed tracing data back into the compiler to improve prediction, but that it never caught on. > MIPS MIPS compilers at one time had lots of flags for telling the compiler what specific MIPS model to target. All models had the same instruction set, but different numbers of functional units, which affected the optimal code order for each model. Software vendors were supposed to provide different executables for each model. That did not go over well.
jcranmer 4y ago
> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? It's closer to the truth to say that Itanium caused the world to become largely x86. In the 90s, while the personal computing market may have been dominated by x86, the workstation and server markets (which was the segment Itanium was targeting) was definitely a lot broader and competitive. HP canceled its own architecture line to focus on Itanium, and a couple of other architectures saw roadmaps dwindle because of it.
- leeter 4y ago
  RISC Architectures confirmed murdered by Itanium: Alpha AXP, MIPS (on the desktop), and HP PA-RISC Architectures set back significantly by Itanium: POWER, SPARC
msla 4y ago
> I believe you are describing VLIW architecture here? Is that correct? Yes. The Itanium was a specific form of VLIW called EPIC, for Explicitly Parallel Instruction Computing: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... Wikipedia lists these modifications EPIC makes to the basic VLIW concept: > Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. The dependency information is calculated by the compiler, so the hardware does not have to perform operand dependency checking. > A software prefetch instruction is used as a type of data prefetch. This prefetch increases the chances for a cache hit for loads, and can indicate the degree of temporal locality needed in various levels of the cache. > A speculative load instruction is used to speculatively load data before it is known whether it will be used (bypassing control dependencies), or whether it will be modified before it is used (bypassing data dependencies). > A check load instruction aids speculative loads by checking whether a speculative load was dependent on a later store, and thus must be reloaded. also: > How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW? That's exactly right: By putting the opcodes in the same word (and/or, in the case of EPIC, in a word subsequent to a previous word without the stop bit set) the entity generating the instruction stream is guaranteeing to the hardware that those opcodes can run in parallel with no problems. > I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? As others said, it was a mix, and, interestingly, the first few Itanium processor generations had a hardware x86 unit to provide compatibility, albeit one that executed x86 code at the speed of 100 MHz Pentium on a 667 MHz Itanium part, and Intel later commissioned software translation, which was actually faster: https://www.informationweek.com/it-life/intel-sees-a-32-bit-hole-in-itanium https://www.informationweek.com/it-life/intel-sees-a-32-bit-... Here's a very informative (but long) bunch of slides about Itanium in theory and practice: https://users.nik.uni-obuda.hu/sima/letoltes/Processor_families_Knowledge_Base_2019/Intels_Itanium_(IA64)_family_2018_10_29.pdf https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil...

leeter 4y ago

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? The answer is: yes Itanium failed because getting instruction parallelism is actually incredibly hard to do and compilers didn't catch up in time to make it matter. But it also failed because of AMD64 which had backwards compat, was cheaper by a lot, and was a lot easier to get decent perf out of. Opinion: I think Itanium was always destined to fail. The idea seems good on paper but fails in practicality because it limits what the hardware can do to achieve speed without breaking backwards compat with itself. You can't have a superscalar Itanium by definition because branch prediction etc. is by design delegated to the compiler. This means that the chips can literally only go up via clock speed, which as we now know doesn't scale forever.

Animats 4y ago
> and compilers didn't catch up in time to make it matter. Yes. I once saw am EE380 talk at Stanford by the HP team working on the Itanium compiler. They had to solve a complicated minimization problem for each block of instructions. It wasn't going well. Branch prediction decisions have to be made at compile time. Intel has built compilers where you feed tracing data back into the compiler to improve prediction, but that it never caught on. > MIPS MIPS compilers at one time had lots of flags for telling the compiler what specific MIPS model to target. All models had the same instruction set, but different numbers of functional units, which affected the optimal code order for each model. Software vendors were supposed to provide different executables for each model. That did not go over well.

jcranmer 4y ago

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? It's closer to the truth to say that Itanium caused the world to become largely x86. In the 90s, while the personal computing market may have been dominated by x86, the workstation and server markets (which was the segment Itanium was targeting) was definitely a lot broader and competitive. HP canceled its own architecture line to focus on Itanium, and a couple of other architectures saw roadmaps dwindle because of it.

leeter 4y ago
RISC Architectures confirmed murdered by Itanium: Alpha AXP, MIPS (on the desktop), and HP PA-RISC Architectures set back significantly by Itanium: POWER, SPARC

msla 4y ago

> I believe you are describing VLIW architecture here? Is that correct? Yes. The Itanium was a specific form of VLIW called EPIC, for Explicitly Parallel Instruction Computing: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... Wikipedia lists these modifications EPIC makes to the basic VLIW concept: > Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. The dependency information is calculated by the compiler, so the hardware does not have to perform operand dependency checking. > A software prefetch instruction is used as a type of data prefetch. This prefetch increases the chances for a cache hit for loads, and can indicate the degree of temporal locality needed in various levels of the cache. > A speculative load instruction is used to speculatively load data before it is known whether it will be used (bypassing control dependencies), or whether it will be modified before it is used (bypassing data dependencies). > A check load instruction aids speculative loads by checking whether a speculative load was dependent on a later store, and thus must be reloaded. also: > How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW? That's exactly right: By putting the opcodes in the same word (and/or, in the case of EPIC, in a word subsequent to a previous word without the stop bit set) the entity generating the instruction stream is guaranteeing to the hardware that those opcodes can run in parallel with no problems. > I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? As others said, it was a mix, and, interestingly, the first few Itanium processor generations had a hardware x86 unit to provide compatibility, albeit one that executed x86 code at the speed of 100 MHz Pentium on a 667 MHz Itanium part, and Intel later commissioned software translation, which was actually faster: https://www.informationweek.com/it-life/intel-sees-a-32-bit-hole-in-itanium https://www.informationweek.com/it-life/intel-sees-a-32-bit-... Here's a very informative (but long) bunch of slides about Itanium in theory and practice: https://users.nik.uni-obuda.hu/sima/letoltes/Processor_families_Knowledge_Base_2019/Intels_Itanium_(IA64)_family_2018_10_29.pdf https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil...