4 ms·

Around the year 2000, Intel decided that the future is Itanium. It didn't matter that the market hated the idea - there was no alternative to Intel, so Intel co

Around the year 2000, Intel decided that the future is Itanium. It didn't matter that the market hated the idea - there was no alternative to Intel, so Intel completely ignored the market's plea for an x86 compatible 64-bit processor that would be able to run old x86 code at native speed. Intel's 32 bit offering at the time wasn't any good either; the pentium had such a deep pipeline (and not so smart prefetch/speculative) that the chips ran at a high frequency, ate a lot of power, but pipeline stages were idling or working on useless stuff a large amount of the time. Luckily for the world, AMD managed to produce that alternative, the AMD64 architecture, which kicked intel's ass so hard that eventually they had to adopt it. If it weren't for AMD's AMD64, and their cross-licensing deal with Intel (that allowed them to make an x86 compatible chip without specifically asking for Intel's permission), we'd be in an Itanium dominated world right now (or .. ARM would have stepped up, it's hard to predict an alternate reality) but surely with less efficient and less effective processors. History does not repeat, but it rhymes. Intel has no Itanic this time, but it did become numb enough to let AMD outmaneuver them again. It's not that Intel is doing a bad job, as much as they have too little incentive to do a good job.

acdha 8y ago
> If it weren't for AMD's AMD64 … we'd be in an Itanium dominated world right now This is far from certain: Itanium shipped years later and much, much below the advertised performance thresholds. In the meantime even Intel’s own x86 had closed the raw performance gap and since IA-64 was such a huge bet on brilliant compilers that the early benchmarks for most business code favored the P-III even before you factored in cost. Similarly, the original claim that it’d offer competitive x86 performance turned out to be half a decade behind years behind when it shipped so it wasn’t even remotely competitive for legacy code and businesses back then had even more weight of code which was difficult to recompile. It’s equally plausible to me that Intel would have continued to see strong x86 sales and weak demand for Itanium and ended up shipping their own 64-bit extension a few years later with less pressure from AMD simply because businesses weren’t keen on the “recompile everything, make a bunch of expensive optimizations, and it might be faster than the system it’s replacing”
- ethbro 8y ago
  Agreed. I think people generally took the wrong lessons from IA-64 (which originated at HP). A) Smart compilers are hard, expensive, and slow to develop B) In 2001, source wasn't open enough for a new ISA to succeed. Not sure it would be now either (chicken / egg for big iron workloads: need marketshare for optimization, need optimization for marketshare) C) Intel absolutely missed the "desktop memory needs are going to expand" trend
  - zzzcpan 8y ago
    I think smart compilers for Itanium is a myth. There is nothing that special about compilers for that architecture. The architecture just wasn't good enough.
    - imtringued 8y ago
      Compilers for VLIW architectures have to implement instruction scheduling at compile time but the information that is required for the best optimizations is only available at runtime.
      - zzzcpan 8y ago
        It's not really a problem for compiled languages, like C, as they provide enough context for static speculation. But the architecture itself has to be well suited for statically speculated general purpose applications, which Itanium wasn't. Today even Russia have managed to produce a VLIW architecture and a good enough compiler [1]. [1] https://en.wikipedia.org/wiki/Elbrus-8S https://en.wikipedia.org/wiki/Elbrus-8S
        acdha 8y ago
        > Today even Russia have managed to produce a VLIW architecture and a good enough compiler Do you have a citation for the “good enough” claim? In particular the listed peak performance appears to be below a modern phone's and, far more importantly, we'd need robust benchmark data to know that it's not following the Itanium cycle where a few very favorable, possibly hand-tuned, benchmarks manage to approach the theoretical maximum but most real-world code is substantially lower.

acdha 8y ago

> If it weren't for AMD's AMD64 … we'd be in an Itanium dominated world right now This is far from certain: Itanium shipped years later and much, much below the advertised performance thresholds. In the meantime even Intel’s own x86 had closed the raw performance gap and since IA-64 was such a huge bet on brilliant compilers that the early benchmarks for most business code favored the P-III even before you factored in cost. Similarly, the original claim that it’d offer competitive x86 performance turned out to be half a decade behind years behind when it shipped so it wasn’t even remotely competitive for legacy code and businesses back then had even more weight of code which was difficult to recompile. It’s equally plausible to me that Intel would have continued to see strong x86 sales and weak demand for Itanium and ended up shipping their own 64-bit extension a few years later with less pressure from AMD simply because businesses weren’t keen on the “recompile everything, make a bunch of expensive optimizations, and it might be faster than the system it’s replacing”

ethbro 8y ago
Agreed. I think people generally took the wrong lessons from IA-64 (which originated at HP). A) Smart compilers are hard, expensive, and slow to develop B) In 2001, source wasn't open enough for a new ISA to succeed. Not sure it would be now either (chicken / egg for big iron workloads: need marketshare for optimization, need optimization for marketshare) C) Intel absolutely missed the "desktop memory needs are going to expand" trend
- zzzcpan 8y ago
  I think smart compilers for Itanium is a myth. There is nothing that special about compilers for that architecture. The architecture just wasn't good enough.
  - imtringued 8y ago
    Compilers for VLIW architectures have to implement instruction scheduling at compile time but the information that is required for the best optimizations is only available at runtime.
    - zzzcpan 8y ago
      It's not really a problem for compiled languages, like C, as they provide enough context for static speculation. But the architecture itself has to be well suited for statically speculated general purpose applications, which Itanium wasn't. Today even Russia have managed to produce a VLIW architecture and a good enough compiler [1]. [1] https://en.wikipedia.org/wiki/Elbrus-8S https://en.wikipedia.org/wiki/Elbrus-8S
      - acdha 8y ago
        > Today even Russia have managed to produce a VLIW architecture and a good enough compiler Do you have a citation for the “good enough” claim? In particular the listed peak performance appears to be below a modern phone's and, far more importantly, we'd need robust benchmark data to know that it's not following the Itanium cycle where a few very favorable, possibly hand-tuned, benchmarks manage to approach the theoretical maximum but most real-world code is substantially lower.