6 ms·

Raymond Chen has a whole "Introduction to IA-64" series of posts on his blog, by the way. It's such an unconventional ISA that I am baffled that Intel seriously

by Joker_vD 11mo ago

Raymond Chen has a whole "Introduction to IA-64" series of posts on his blog, by the way. It's such an unconventional ISA that I am baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86: it's very poorly suited for general-purpose computations. Number crunching, sure, but anything more freeform, and you stare at the specs and wonder how the hell the designers supposed this thing to be programmed and used.

yongjik 11mo ago
Well, they did persuade HP to ditch their own homegrown PA-RISC architecture and jump on board with Itanium, so there's that. I wonder how much that decision contributed to the eventual demise of HP's high performance server division ...
- classichasclass 11mo ago
  A lot, I think. PA-RISC had a lot going for it, high performance, solid ISA, even some low-end consumer grade parts (not to the same degree as PowerPC but certainly more so than, say, SPARC). It could have gone much farther than it did. Not that HP was the only one to lose their minds over Itanic (SGI in particular), but I thought they were the ones who walked away from the most.
  - pjc50 11mo ago
    Am I right in thinking that the old PA-Semi team was bought by Apple, and are substantially responsible for the success of the M-series parts?
    - scrlk 11mo ago
      Acquiring P.A. Semi got them Dan Dobberpuhl and Jim Keller, which laid a good design foundation. However, IMO, I'd lean towards these as the decisive factors today: 1) Apple's financial firepower allowing them to book out SOTA process nodes 2) Apple being less cost-sensitive in their designs vs. Qualcomm or Intel. Since Apple sells devices, they can justify 'expensive' decisions like massive caches that require significantly more die area.
      - bombcar 11mo ago
        They also had years to keep improving the iPhone chips until they were so good at power efficiency that they could slap it into a laptop. That’s much better than a decade of development with no product yet.
    - sgerenser 11mo ago
      PA Semi (Palo Alto Semiconductor) had no relation to HP’s PA-RISC (Precision Architecture RISC).
    - classichasclass 11mo ago
      P.A. Semi contributed greatly to Apple silicon, but the company has nothing to do with PA-RISC. In fact, their most notable chip before Apple bought them was Power ISA.
msla 11mo ago
"We don't care, we don't have to, we're Intel." Plus, DEC managed to move all of its VAX users to Alpha through the simple expedient of no longer making VAXen, so I wonder if HP (which by that point had swallowed what used to be DEC) thought it could repeat that trick and sunset x86, which Intel has wanted to do for very nearly as long as the x86 has existed. See also: Intel i860 https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860
- kruador 11mo ago
  The 8086 was a stop-gap solution until iAPX432 was ready. The 80286 was a stop-gap solution until iAPX432 was ready. The 80386 started as a stop-gap solution until iAPX432 was ready, until someone higher up finally decided to kill that one.
  - pjc50 11mo ago
    https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 I'd never heard of it myself, and reading that Wikipedia page it seems to have been a collection of every possible technology that didn't pan out in IC-language-OS codesign. Meanwhile, in Britain a few years later in 1985, a small company and a dedicated engineer, Sophie Wilson, decided that what they needed was a RISC processor that was as plain and straightforward as possible ...
AndrewStephens 11mo ago
I remember when IA-64 was going to be the next big thing and being utterly baffled when the instruction set was made public. Even if you could somehow ship code that efficiently used the weird instruction bundles, there was no indication that future IA-64 CPUs would have the same limits for instruction grouping. It did make a tiny bit of sense at the time. Java was ascendant and I think Intel assumed that JIT compiled languages were going to dominate the new century and that a really good compiler could unlock performance. It was not to be.
- kragen 11mo ago
  That is not what happened. EPIC development at HP started in 01989, and the Intel collaboration was publicly announced in 01994. The planned ship date for Merced, the first Itanic, was 01998, and it was first floorplanned in 01996, the year Java was announced. Merced finally taped out in July 01999, three months after the first JIT option for the JVM shipped. Nobody was assuming that JIT compiled languages were going to dominate the new century at that time, although there were some promising signs from Self and Strongtalk that maybe they could be half as fast as C.
  - AndrewStephens 11mo ago
    By the time IA-64 actually got close to shipping Intel was certainly talking about JIT being a factor in its success. At least that was mentioned in the marketing guff they were putting out.
    - kragen 11mo ago
      You mean, in 01999? I'd have to see that, because my recollection of that time is that JIT was generally considered unproven (and Java slow). That was 9 years before Chrome shipped the first JavaScript JIT, for example. The only existing commercial products using JIT were Smalltalk implementations like VisualAge, which were also slow. Even HP's "Dynamo" research prototype paper wasn't published until 02000. Or do you not count Merced as "shipping"?
jcranmer 11mo ago
Some guesses here: First off, Itanium was definitely meant to be the 64-bit successor to x86 (that's why it's called IA-64 after all), and moving from 32-bit to 64-bit would absolutely have been a killer feature. It's basically only after the underwhelming launch of Itanium that AMD comes out with AMD64, which becomes the actual 64-bit version of x86; once that comes out, the 64-bitness of Itanium is no longer a differentiation. Second... given that Itanium basically implements every weird architecture feature you've ever heard of, my guess is that they decided they had the resources to make all of this stuff work. And they got into a bubble where they just simply ignored any countervailing viewpoints anytime someone brought up a problem. (This does seem to be a particular specialty of Intel.) Third, there's definitely a baseline assumption of a sufficiently-smart compiler. And my understanding is that the Intel compiler was actually halfway decent at Itanium, whereas gcc was absolute shit at it. So while some aspects of the design are necessarily inferior (a sufficiently-smart compiler will never be as good at hardware at scavenging ILP, hardware architects, so please stop trying to foist that job on us compiler writers), it actually did do reasonably well on performance in the HPC sector.
- happosai 11mo ago
  It appeared to me (from far outside) that Intel was trying to segment the market into "Affordable Home and office PC:s with x86" and "Expensive serious computing with itanium". Having everything so different was a feature, to justify the eyewateringly expensive itanium pricetag.
  - Earw0rm 11mo ago
    The IBM PS/2 play. And we all know how well that one worked out.
    - happosai 11mo ago
      I'm sure it worked out for many bosses. They got their bonuses and promotions and someone else got to clean up mess.
  - kuschku 11mo ago
fulafel 11mo ago
> baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86 They did persuade SGI, DEC and HP to switch from their RISCs to it though. Which turned out to be rather good for business.
- zinekeller 11mo ago
  SGI and DEC, yes, but HP? Itanium was HP's idea all along! [1] [1] https://en.wikipedia.org/wiki/Itanium#History https://en.wikipedia.org/wiki/Itanium#History
  - fulafel 11mo ago
    You're right of course.
- fredoralive 11mo ago
  I suspect SGI and DEC / Compaq could look at a chart and see that with P6 Intel was getting very close to their RISC chips, through the power of MONEY (simplification). They weren't hitting a CISC wall, and the main moat custom RISC had left was 64 bit. Intel's 64 bit chip would inevitably become the standard chip for PCs, and therefore Intel would be able to turn its money cannon onto overpowering all 64 bit RISCs in short order. May as well get aboard the 64 bit Intel train early. Which is nearly true 64 bit Intel chips did (mostly) kill RISC. But not their (and HP's) fun science project IA64, they had to copy AMD's "what if x86, but 64 bit?" idea instead.
kragen 11mo ago
They took technical risks that didn't pan out. They thought they'd be able to solve whatever problems they ran into, but they couldn't. They didn't know ahead of time that the result was going to suck. If you try to run an actual tech company, like Intel, without taking any technical risks, competitors who do take technical risks will leave you in the dust. This doesn't apply to fake tech companies like AirBnB, Dropbox, and Stripe, and if you've spent your career at fake tech companies, your intuition is going to be "off" on this point.
- eru 11mo ago
  Computer hardware isn't the only 'tech' that exists, you know? Problems in operations research (like logistics) or fraud detection can be just as technical.
  - kragen 11mo ago
    Fraud detection is a Red Queen's race. If the amount of resources that goes into fraud detection and fraud commission grows by 10×, 100×, 1000×, the resulting increase in human capacities and improvement in human welfare will be nil. It may be technically challenging but it isn't technology. Operations research is technology, but Uber isn't Gurobi, which is a real tech company like Intel, however questionable their ethics may be.
    - eru 11mo ago
      > Operations research is technology, but Uber isn't Gurobi, [...] Intel isn't ASML, either. They merely use their products. So what? Presumably Gurobi doesn't write their own compilers or fab their own chips. It's turtles all the way down. > Fraud detection is a Red Queen's race. If the amount of resources that goes into fraud detection and fraud commission grows by 10×, 100×, 1000×, the resulting increase in human capacities and improvement in human welfare will be nil. It may be technically challenging but it isn't technology. By that logic no military anywhere uses any technology? Nor is there any technology in Formula 1 cars?
      - 11mo ago
pjmlp 11mo ago
Itanium only failed because AMD for various reasons was able to come up with AMD64 and rug pull Intel's efforts. In an alternative universe without AMD64, Intel would have kept pushing Itanium while sorting out its issues, HP-UX was on it, and Windows XP as well.
- pjc50 11mo ago
  Other way round: the only way any company other than Intel was able to get a new instruction set launched into the PC space was because Intel face-planted so hard with Itanium, and AMD64 was the architecture developers actually wanted to use - just make the registers wider and have more of them, and make it slightly more orthogonal.
  - pjmlp 11mo ago
    Developers get to use the architectures OEM vendors make available to them.
    - pjc50 11mo ago
      Sure, but the fact remains that AMD64 won in the market, despite the incumbent near-monopoly "Wintel" advantages.
      - pjmlp 11mo ago
        The whole premise is that it only won because AMD exists, and was allowed to come up with it. People don't read comments before replying?
        Joker_vD 11mo ago
        In that different world, Transmeta would actually succeed in the market of x86-compatible CPUs and, perhaps, would even come up with their own 64-bit extension. Itanium would still flop. Or maybe, if the push came to shove, the desktops would switch to something entirely different like Alpha. Or ARM! Such event would likely force ARM to come up with their AArch64 several years sooner than it actually happened.
eru 11mo ago
> It's such an unconventional ISA that I am baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86 [...] I don't know, most people don't care about the ISA being weird as long as the compiler produces reasonably fast code?

yongjik 11mo ago

Well, they did persuade HP to ditch their own homegrown PA-RISC architecture and jump on board with Itanium, so there's that. I wonder how much that decision contributed to the eventual demise of HP's high performance server division ...

classichasclass 11mo ago
A lot, I think. PA-RISC had a lot going for it, high performance, solid ISA, even some low-end consumer grade parts (not to the same degree as PowerPC but certainly more so than, say, SPARC). It could have gone much farther than it did. Not that HP was the only one to lose their minds over Itanic (SGI in particular), but I thought they were the ones who walked away from the most.
- pjc50 11mo ago
  Am I right in thinking that the old PA-Semi team was bought by Apple, and are substantially responsible for the success of the M-series parts?
  - scrlk 11mo ago
    Acquiring P.A. Semi got them Dan Dobberpuhl and Jim Keller, which laid a good design foundation. However, IMO, I'd lean towards these as the decisive factors today: 1) Apple's financial firepower allowing them to book out SOTA process nodes 2) Apple being less cost-sensitive in their designs vs. Qualcomm or Intel. Since Apple sells devices, they can justify 'expensive' decisions like massive caches that require significantly more die area.
    - bombcar 11mo ago
      They also had years to keep improving the iPhone chips until they were so good at power efficiency that they could slap it into a laptop. That’s much better than a decade of development with no product yet.
  - sgerenser 11mo ago
    PA Semi (Palo Alto Semiconductor) had no relation to HP’s PA-RISC (Precision Architecture RISC).
  - classichasclass 11mo ago
    P.A. Semi contributed greatly to Apple silicon, but the company has nothing to do with PA-RISC. In fact, their most notable chip before Apple bought them was Power ISA.

msla 11mo ago

"We don't care, we don't have to, we're Intel." Plus, DEC managed to move all of its VAX users to Alpha through the simple expedient of no longer making VAXen, so I wonder if HP (which by that point had swallowed what used to be DEC) thought it could repeat that trick and sunset x86, which Intel has wanted to do for very nearly as long as the x86 has existed. See also: Intel i860 https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860

kruador 11mo ago
The 8086 was a stop-gap solution until iAPX432 was ready. The 80286 was a stop-gap solution until iAPX432 was ready. The 80386 started as a stop-gap solution until iAPX432 was ready, until someone higher up finally decided to kill that one.
- pjc50 11mo ago
  https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 I'd never heard of it myself, and reading that Wikipedia page it seems to have been a collection of every possible technology that didn't pan out in IC-language-OS codesign. Meanwhile, in Britain a few years later in 1985, a small company and a dedicated engineer, Sophie Wilson, decided that what they needed was a RISC processor that was as plain and straightforward as possible ...

AndrewStephens 11mo ago

I remember when IA-64 was going to be the next big thing and being utterly baffled when the instruction set was made public. Even if you could somehow ship code that efficiently used the weird instruction bundles, there was no indication that future IA-64 CPUs would have the same limits for instruction grouping. It did make a tiny bit of sense at the time. Java was ascendant and I think Intel assumed that JIT compiled languages were going to dominate the new century and that a really good compiler could unlock performance. It was not to be.

kragen 11mo ago
That is not what happened. EPIC development at HP started in 01989, and the Intel collaboration was publicly announced in 01994. The planned ship date for Merced, the first Itanic, was 01998, and it was first floorplanned in 01996, the year Java was announced. Merced finally taped out in July 01999, three months after the first JIT option for the JVM shipped. Nobody was assuming that JIT compiled languages were going to dominate the new century at that time, although there were some promising signs from Self and Strongtalk that maybe they could be half as fast as C.
- AndrewStephens 11mo ago
  By the time IA-64 actually got close to shipping Intel was certainly talking about JIT being a factor in its success. At least that was mentioned in the marketing guff they were putting out.
  - kragen 11mo ago
    You mean, in 01999? I'd have to see that, because my recollection of that time is that JIT was generally considered unproven (and Java slow). That was 9 years before Chrome shipped the first JavaScript JIT, for example. The only existing commercial products using JIT were Smalltalk implementations like VisualAge, which were also slow. Even HP's "Dynamo" research prototype paper wasn't published until 02000. Or do you not count Merced as "shipping"?

jcranmer 11mo ago

Some guesses here: First off, Itanium was definitely meant to be the 64-bit successor to x86 (that's why it's called IA-64 after all), and moving from 32-bit to 64-bit would absolutely have been a killer feature. It's basically only after the underwhelming launch of Itanium that AMD comes out with AMD64, which becomes the actual 64-bit version of x86; once that comes out, the 64-bitness of Itanium is no longer a differentiation. Second... given that Itanium basically implements every weird architecture feature you've ever heard of, my guess is that they decided they had the resources to make all of this stuff work. And they got into a bubble where they just simply ignored any countervailing viewpoints anytime someone brought up a problem. (This does seem to be a particular specialty of Intel.) Third, there's definitely a baseline assumption of a sufficiently-smart compiler. And my understanding is that the Intel compiler was actually halfway decent at Itanium, whereas gcc was absolute shit at it. So while some aspects of the design are necessarily inferior (a sufficiently-smart compiler will never be as good at hardware at scavenging ILP, hardware architects, so please stop trying to foist that job on us compiler writers), it actually did do reasonably well on performance in the HPC sector.

happosai 11mo ago
It appeared to me (from far outside) that Intel was trying to segment the market into "Affordable Home and office PC:s with x86" and "Expensive serious computing with itanium". Having everything so different was a feature, to justify the eyewateringly expensive itanium pricetag.
- Earw0rm 11mo ago
  The IBM PS/2 play. And we all know how well that one worked out.
  - happosai 11mo ago
    I'm sure it worked out for many bosses. They got their bonuses and promotions and someone else got to clean up mess.
- kuschku 11mo ago

fulafel 11mo ago

> baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86 They did persuade SGI, DEC and HP to switch from their RISCs to it though. Which turned out to be rather good for business.

zinekeller 11mo ago
SGI and DEC, yes, but HP? Itanium was HP's idea all along! [1] [1] https://en.wikipedia.org/wiki/Itanium#History https://en.wikipedia.org/wiki/Itanium#History
- fulafel 11mo ago
  You're right of course.
fredoralive 11mo ago
I suspect SGI and DEC / Compaq could look at a chart and see that with P6 Intel was getting very close to their RISC chips, through the power of MONEY (simplification). They weren't hitting a CISC wall, and the main moat custom RISC had left was 64 bit. Intel's 64 bit chip would inevitably become the standard chip for PCs, and therefore Intel would be able to turn its money cannon onto overpowering all 64 bit RISCs in short order. May as well get aboard the 64 bit Intel train early. Which is nearly true 64 bit Intel chips did (mostly) kill RISC. But not their (and HP's) fun science project IA64, they had to copy AMD's "what if x86, but 64 bit?" idea instead.

kragen 11mo ago

They took technical risks that didn't pan out. They thought they'd be able to solve whatever problems they ran into, but they couldn't. They didn't know ahead of time that the result was going to suck. If you try to run an actual tech company, like Intel, without taking any technical risks, competitors who do take technical risks will leave you in the dust. This doesn't apply to fake tech companies like AirBnB, Dropbox, and Stripe, and if you've spent your career at fake tech companies, your intuition is going to be "off" on this point.

eru 11mo ago
Computer hardware isn't the only 'tech' that exists, you know? Problems in operations research (like logistics) or fraud detection can be just as technical.
- kragen 11mo ago
  Fraud detection is a Red Queen's race. If the amount of resources that goes into fraud detection and fraud commission grows by 10×, 100×, 1000×, the resulting increase in human capacities and improvement in human welfare will be nil. It may be technically challenging but it isn't technology. Operations research is technology, but Uber isn't Gurobi, which is a real tech company like Intel, however questionable their ethics may be.
  - eru 11mo ago
    > Operations research is technology, but Uber isn't Gurobi, [...] Intel isn't ASML, either. They merely use their products. So what? Presumably Gurobi doesn't write their own compilers or fab their own chips. It's turtles all the way down. > Fraud detection is a Red Queen's race. If the amount of resources that goes into fraud detection and fraud commission grows by 10×, 100×, 1000×, the resulting increase in human capacities and improvement in human welfare will be nil. It may be technically challenging but it isn't technology. By that logic no military anywhere uses any technology? Nor is there any technology in Formula 1 cars?
    - 11mo ago

pjmlp 11mo ago

Itanium only failed because AMD for various reasons was able to come up with AMD64 and rug pull Intel's efforts. In an alternative universe without AMD64, Intel would have kept pushing Itanium while sorting out its issues, HP-UX was on it, and Windows XP as well.

pjc50 11mo ago
Other way round: the only way any company other than Intel was able to get a new instruction set launched into the PC space was because Intel face-planted so hard with Itanium, and AMD64 was the architecture developers actually wanted to use - just make the registers wider and have more of them, and make it slightly more orthogonal.
- pjmlp 11mo ago
  Developers get to use the architectures OEM vendors make available to them.
  - pjc50 11mo ago
    Sure, but the fact remains that AMD64 won in the market, despite the incumbent near-monopoly "Wintel" advantages.
    - pjmlp 11mo ago
      The whole premise is that it only won because AMD exists, and was allowed to come up with it. People don't read comments before replying?
      - Joker_vD 11mo ago
        In that different world, Transmeta would actually succeed in the market of x86-compatible CPUs and, perhaps, would even come up with their own 64-bit extension. Itanium would still flop. Or maybe, if the push came to shove, the desktops would switch to something entirely different like Alpha. Or ARM! Such event would likely force ARM to come up with their AArch64 several years sooner than it actually happened.

eru 11mo ago

> It's such an unconventional ISA that I am baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86 [...] I don't know, most people don't care about the ISA being weird as long as the compiler produces reasonably fast code?