5 ms·

I remember at the time thinking it was really silly for Intel to release a 64-bit processor that broke compatibility, and was very glad AMD kept it. Years later

by bigstrat2003 1y ago

I remember at the time thinking it was really silly for Intel to release a 64-bit processor that broke compatibility, and was very glad AMD kept it. Years later I learned about kernel writing, and I now get why Intel tried to break with the old - the compatibility hacks piled up on x86 are truly awful. But ultimately, customers don't care about that, they just want their stuff to run.

zokier 1y ago
It is worth noting that at the turn of the century x86 wasn't yet so utterly dominant yet. Alphas, PowerPC, MIPS, SPARC and whatnot were still very much a thing. So that is part why running x86 software was not as high priority, and maybe even compatibility with PA-RISC would have been a higher priority.
- tliltocatl 1y ago
  Well, according to some IA-64 was a planned flop with the whole purpose of undermining HP's supercomputer division.
  - cogman10 1y ago
    Nah, HP made bank on their superdome computers even though they had very few clients. People paid through the nose for those. I worked on IA-64 stuff in 2011, long after I thought it was dead :D. The real thing that killed the division is Oracle announcing that they would no longer support IA-64. It just so happened that like 90% of the clients using Itanium were using it for oracle DBs. But by that point HP was already trying to get people to transition to more traditional x86 servers that they were selling.
    - hawflakes 1y ago
      The hardware folks at HP were big into the outdoors. The story went that it was named Halfdome but customers outside the US who weren't familiar with Yosemite would ask where the other half was. https://en.wikipedia.org/wiki/Half_Dome https://en.wikipedia.org/wiki/Half_Dome
- Spooky23 1y ago
  The writing was on the wall once Linux was a thing. I did alot of solution design in that period. The only times there were good business cases in my world for not-x86 were scenarios where DBAs and some vertical software required Sun, and occasionally AIX or HPUX for license optimization or some weird mainframe finance scheme. The cost structure was just bonkers. I replaced a big file server environment that was like $2M of Sun gear with like $600k of HP Proliant.
  - michaelt 1y ago
    And by ~2000 there were also increasingly viable x86 offerings in CAD, 3D and video editing. You had AutoCAD, you had 3D Studio Max, you had After Effects, you had Adobe Premiere. And it was solid stuff - maybe not best-in-class, but good enough, and the price was right.
  - rollcat 1y ago
    > The writing was on the wall once Linux was a thing. Linux didn't "win" nearly as much as x86 did by becoming "good enough" - Linux just happened to be around to capitalize on that victory. The writing on the wall was the decreasing prices and increasing capability of consumer-grade hardware. Then real game-changer followed: horizontal scalability.
- unethical_ban 1y ago
  Is that true in 2000, especially as consumer PCs ramped up?
wvenable 1y ago
Intel might have been successful with the transition if they didn't decide to go with such radically different and real-world untested architecture for Itanium.
- pixl97 1y ago
  Well that and Itanium was eyewateringly expensive and standard PC was much cheaper for similar or faster speeds.
  - Tsiklon 1y ago
    I think Itanium was a remarkable success in some other ways. Intel utterly destroyed the workstation market with it. HP-UX, IRIX, AIX, Solaris. Itanium sounded the deathknell for all of them. The only Unix to survive with any market share is MacOS, (arguably because of its lateness to the party) and it has only relatively recently went back to a more bespoke architecture
    - icedchai 1y ago
      I'd argue it was Linux (on x86) and the dot-com crash that destroyed the workstation market, not Itanium. The early 2000s was awash in used workstation gear, especially Sun. I've never seen anyone with an Itanium box.
      - tyingq 1y ago
        I think the idea there is that it's less direct. Intel's lack of interest in a 64-bit x86 spawned AMD x64. The failure of Itanium then let that Linux/AMD x64 kill off the workstation market, and the larger RISC/Unix market. Linux on 32 bit X86 or 64 bit RISC alone was making some headway there, but the Linux/x64 combo is what enabled the full kill off.
        p_l 1y ago
        Intel's lack of interest in delivering 64bit for "peons" running x86 also was part - I remember when first discussion in popular computer magazines showed of amd64, that intel's proposed timeline was discussed, and it very much indicated a wish to push for "buy our super expensive stuff" and trying to squeeze money. Meanwhile the decision to keep Itanium on expensive but lower-volume market meant that there simply wasn't much market growth, especially once non-technical part of killing other RISCs failed. Ultimately Itanium was left as recommended way in some markets to run Oracle databases (due to partnership between Oracle and HP) and not much else, while shops that used other RISC platforms either migrated to AMD64, or moved to other RISC platforms (even forcing HP to resurrect Alpha for last one gen)
drewg123 1y ago
It didn't help that Itanium was late, slow, and Intel/HP marketing used Itanium to kill off the various RISC CPUs, each of which had very loyal fans. This pissed off a lot of techies at the time. I was a HUGE DEC Alpha fanboy at the time (even helped port FreeBSD to DEC Alpha), so I hated Itanium with a passion. I'm sure people like me who were 64-bit MIPS and PA-RISC fanboys and fangrirls also existed, and also lobbied against adoption of itanic where they could. I remember when amd64 appeared, and it just made so much sense.
- EasyMark 1y ago
  This, if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on. However no one in IT was fool enough to switch architectures over a 30-50% performance improvement that require switching hardware, compilers, and software and try to sell it to their bosses.
  - axiolite 1y ago
    > if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on. That sounds like DEC Alpha to me, yet Alpha didn't take over the world. "Proprietary architecture" is a bad word, not something you want to base your future on. Without the Intel/AMD competition, x86 wouldn't have dominated for all these years.
    - cameldrv 1y ago
      The DEC Alpha actually did provide very good performance, and you could even run Windows NT on it. As far as I can tell, the biggest problem was just that Alpha systems were very expensive, and so they had a limited customer base. There were some quirks, but the main thing was just that you'd be paying $2000 for a PC and $10,000 for an Alpha based system, and most people didn't need the performance that badly.
      - axiolite 1y ago
        > Alpha systems were very expensive, and so they had a limited customer base. That's the usual chicken & egg problem... If they sold more units, the prices would have come down. But people weren't buying many, because the prices were high. Itanium, like Alpha, or any other alternative architecture, would also have trouble and get stuck in that circle. x86-64, being a very inexpensive add-on to x86, managed to avoid that.
irusensei 1y ago
I heard AMD64 uses some DEC Alpha tricks. Guess DEC engineers did had a last laugh against intel in the end.
Romario77 1y ago
It wasn't just incompatibility, it was some of the design decisions that made it very hard to make performant code that runs well on Itanium. Intel made a bet on parallel processing and compilers figuring out how to organize instructions instead of doing this in silicone. It proved to be very hard to do, so the supposedly next gen processors turned out to be more expensive and slower than the last gen or new AMD ones.
- cameldrv 1y ago
  Yeah the biggest idea was essentially to do the scheduling of instructions upfront in the compiler instead of dynamically at runtime. By doing this, you can save a ton of die area for control and put it into functional units doing math etc. The problem as far as I can tell as a layman is that the compiler simply doesn't have enough information to do this job at compile time. The timing of the CPU is not deterministic in the real world because caches can miss unpredictably, even depending on what other processes are running at the same time on the computer. Branches also can be different depending on the data being processed. Branch predictors and prefetchers can optimize this at runtime using the actual statistics of what's happening in that particular execution of the program. Better compilers can do profile directed optimization, but it's still going to be optimized for the particular situation the CPU was in during the profile run(s). If you think of a program like an interpreter running a tight loop in an interpreted program, a good branch predictor and prefetcher are probably going to be able to predict fairly well, but a statically scheduled CPU is in trouble because at the compile time of the interpreter, the compiler has no idea what program the interpreter is going to be running.

zokier 1y ago

It is worth noting that at the turn of the century x86 wasn't yet so utterly dominant yet. Alphas, PowerPC, MIPS, SPARC and whatnot were still very much a thing. So that is part why running x86 software was not as high priority, and maybe even compatibility with PA-RISC would have been a higher priority.

tliltocatl 1y ago
Well, according to some IA-64 was a planned flop with the whole purpose of undermining HP's supercomputer division.
- cogman10 1y ago
  Nah, HP made bank on their superdome computers even though they had very few clients. People paid through the nose for those. I worked on IA-64 stuff in 2011, long after I thought it was dead :D. The real thing that killed the division is Oracle announcing that they would no longer support IA-64. It just so happened that like 90% of the clients using Itanium were using it for oracle DBs. But by that point HP was already trying to get people to transition to more traditional x86 servers that they were selling.
  - hawflakes 1y ago
    The hardware folks at HP were big into the outdoors. The story went that it was named Halfdome but customers outside the US who weren't familiar with Yosemite would ask where the other half was. https://en.wikipedia.org/wiki/Half_Dome https://en.wikipedia.org/wiki/Half_Dome
Spooky23 1y ago
The writing was on the wall once Linux was a thing. I did alot of solution design in that period. The only times there were good business cases in my world for not-x86 were scenarios where DBAs and some vertical software required Sun, and occasionally AIX or HPUX for license optimization or some weird mainframe finance scheme. The cost structure was just bonkers. I replaced a big file server environment that was like $2M of Sun gear with like $600k of HP Proliant.
- michaelt 1y ago
  And by ~2000 there were also increasingly viable x86 offerings in CAD, 3D and video editing. You had AutoCAD, you had 3D Studio Max, you had After Effects, you had Adobe Premiere. And it was solid stuff - maybe not best-in-class, but good enough, and the price was right.
- rollcat 1y ago
  > The writing was on the wall once Linux was a thing. Linux didn't "win" nearly as much as x86 did by becoming "good enough" - Linux just happened to be around to capitalize on that victory. The writing on the wall was the decreasing prices and increasing capability of consumer-grade hardware. Then real game-changer followed: horizontal scalability.
unethical_ban 1y ago
Is that true in 2000, especially as consumer PCs ramped up?

wvenable 1y ago

Intel might have been successful with the transition if they didn't decide to go with such radically different and real-world untested architecture for Itanium.

pixl97 1y ago
Well that and Itanium was eyewateringly expensive and standard PC was much cheaper for similar or faster speeds.
- Tsiklon 1y ago
  I think Itanium was a remarkable success in some other ways. Intel utterly destroyed the workstation market with it. HP-UX, IRIX, AIX, Solaris. Itanium sounded the deathknell for all of them. The only Unix to survive with any market share is MacOS, (arguably because of its lateness to the party) and it has only relatively recently went back to a more bespoke architecture
  - icedchai 1y ago
    I'd argue it was Linux (on x86) and the dot-com crash that destroyed the workstation market, not Itanium. The early 2000s was awash in used workstation gear, especially Sun. I've never seen anyone with an Itanium box.
    - tyingq 1y ago
      I think the idea there is that it's less direct. Intel's lack of interest in a 64-bit x86 spawned AMD x64. The failure of Itanium then let that Linux/AMD x64 kill off the workstation market, and the larger RISC/Unix market. Linux on 32 bit X86 or 64 bit RISC alone was making some headway there, but the Linux/x64 combo is what enabled the full kill off.
      - p_l 1y ago
        Intel's lack of interest in delivering 64bit for "peons" running x86 also was part - I remember when first discussion in popular computer magazines showed of amd64, that intel's proposed timeline was discussed, and it very much indicated a wish to push for "buy our super expensive stuff" and trying to squeeze money. Meanwhile the decision to keep Itanium on expensive but lower-volume market meant that there simply wasn't much market growth, especially once non-technical part of killing other RISCs failed. Ultimately Itanium was left as recommended way in some markets to run Oracle databases (due to partnership between Oracle and HP) and not much else, while shops that used other RISC platforms either migrated to AMD64, or moved to other RISC platforms (even forcing HP to resurrect Alpha for last one gen)

drewg123 1y ago

It didn't help that Itanium was late, slow, and Intel/HP marketing used Itanium to kill off the various RISC CPUs, each of which had very loyal fans. This pissed off a lot of techies at the time. I was a HUGE DEC Alpha fanboy at the time (even helped port FreeBSD to DEC Alpha), so I hated Itanium with a passion. I'm sure people like me who were 64-bit MIPS and PA-RISC fanboys and fangrirls also existed, and also lobbied against adoption of itanic where they could. I remember when amd64 appeared, and it just made so much sense.

EasyMark 1y ago
This, if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on. However no one in IT was fool enough to switch architectures over a 30-50% performance improvement that require switching hardware, compilers, and software and try to sell it to their bosses.
- axiolite 1y ago
  > if intel's compilers and architecture had been stellar and provided a x5 or x10 improvement it would have caught on. That sounds like DEC Alpha to me, yet Alpha didn't take over the world. "Proprietary architecture" is a bad word, not something you want to base your future on. Without the Intel/AMD competition, x86 wouldn't have dominated for all these years.
  - cameldrv 1y ago
    The DEC Alpha actually did provide very good performance, and you could even run Windows NT on it. As far as I can tell, the biggest problem was just that Alpha systems were very expensive, and so they had a limited customer base. There were some quirks, but the main thing was just that you'd be paying $2000 for a PC and $10,000 for an Alpha based system, and most people didn't need the performance that badly.
    - axiolite 1y ago
      > Alpha systems were very expensive, and so they had a limited customer base. That's the usual chicken & egg problem... If they sold more units, the prices would have come down. But people weren't buying many, because the prices were high. Itanium, like Alpha, or any other alternative architecture, would also have trouble and get stuck in that circle. x86-64, being a very inexpensive add-on to x86, managed to avoid that.

irusensei 1y ago

I heard AMD64 uses some DEC Alpha tricks. Guess DEC engineers did had a last laugh against intel in the end.

Romario77 1y ago

It wasn't just incompatibility, it was some of the design decisions that made it very hard to make performant code that runs well on Itanium. Intel made a bet on parallel processing and compilers figuring out how to organize instructions instead of doing this in silicone. It proved to be very hard to do, so the supposedly next gen processors turned out to be more expensive and slower than the last gen or new AMD ones.

cameldrv 1y ago
Yeah the biggest idea was essentially to do the scheduling of instructions upfront in the compiler instead of dynamically at runtime. By doing this, you can save a ton of die area for control and put it into functional units doing math etc. The problem as far as I can tell as a layman is that the compiler simply doesn't have enough information to do this job at compile time. The timing of the CPU is not deterministic in the real world because caches can miss unpredictably, even depending on what other processes are running at the same time on the computer. Branches also can be different depending on the data being processed. Branch predictors and prefetchers can optimize this at runtime using the actual statistics of what's happening in that particular execution of the program. Better compilers can do profile directed optimization, but it's still going to be optimized for the particular situation the CPU was in during the profile run(s). If you think of a program like an interpreter running a tight loop in an interpreted program, a good branch predictor and prefetcher are probably going to be able to predict fairly well, but a statically scheduled CPU is in trouble because at the compile time of the interpreter, the compiler has no idea what program the interpreter is going to be running.