4 ms·

> Intel and AMD don't build features no one asks for. Hmmm. Intel has built whole ISAs that no one asked for and didn’t want.

ethbr0 5y ago
If you're referring to IA-64, then what information available in 1994 would have made you believe that VLIW / EPIC wasn't a viable path to provide >1 IPC at competitive clock speeds? Something very many customers were asking for and wanted. Some good ideas work. Some good ideas don't. Doesn't mean they were bad ideas, only that unknown at the time factors or future developments made them bad ideas.
- klelatti 5y ago
  I wasn’t thinking of IA-64 actually. Not sure how the rest of your comment relates to my point though. Customers may want better performance. Doesn’t mean they want your new architecture. They certainly didn’t want IA-64. That’s just a statement of fact.
  - ethbr0 5y ago
    Which ISA were you talking about? And as for the link between architecture and performance, I'll turn the common quip: "You can have performance or architecture changes, pick two." The debate between runtime parallelism vs compiler parallelism, and which would result in greater performance on real world workloads, was an open question at the time. As it turned out, the market preferred answer was "Screw it, we'll push superscalar and add more cores." But that's non-obvious in foresight. See: the famous P68/NetBurst/Pentium 4 vs P6+/Pentium M struggles.
    - klelatti 5y ago
      I broadly agree that it was non obvious and don’t really blame Intel for trying IA-64. I was really (semi humorously) trying to push back against the parent comment saying that everything these firms have done has arisen directly from customer demand. Obviously firms must think that there is demand for new products or features but sometimes they just misunderstand the market. To give another example was there really any demand from customers for x86 cores in smartphones or was it Intel just trying to establish a market presence? To answer your question iAPX432.
      - ethbr0 5y ago
        iAPX432 is a good example. :-) But in the early-80s, Symbolics was making a lot of noise with Lisp machines, the late-80s AI winter hadn't yet set in, and there were certainly worse bets than CISCy "we need to integrate up the stack" ideas. x86 on mobile is a hard one. I see why Intel did it: it's what they had. And I'm sure Microsoft was whispering some demand in their ear behind the scenes. But it really only made strategic sense pre-App Store volume (so say pre-2010?). Once the mass of code existed on ARM and built for iOS, that genie wasn't going back in the bottle. As far as I've heard it told, that was more of a financial business decision though. Intel wasn't willing to cut its margins, because it couldn't see trading volume for margin as mobile exploded. If they'd been able to offer the market cheap, sufficiently performant, power efficient chips for mobile, I think present would look a lot different.
- kps 5y ago
  > what information available in 1994 would have made you believe that VLIW / EPIC wasn't a viable path The i860. High peak performance on paper, realizable in approximately zero real-world code.

ethbr0 5y ago

If you're referring to IA-64, then what information available in 1994 would have made you believe that VLIW / EPIC wasn't a viable path to provide >1 IPC at competitive clock speeds? Something very many customers were asking for and wanted. Some good ideas work. Some good ideas don't. Doesn't mean they were bad ideas, only that unknown at the time factors or future developments made them bad ideas.

klelatti 5y ago
I wasn’t thinking of IA-64 actually. Not sure how the rest of your comment relates to my point though. Customers may want better performance. Doesn’t mean they want your new architecture. They certainly didn’t want IA-64. That’s just a statement of fact.
- ethbr0 5y ago
  Which ISA were you talking about? And as for the link between architecture and performance, I'll turn the common quip: "You can have performance or architecture changes, pick two." The debate between runtime parallelism vs compiler parallelism, and which would result in greater performance on real world workloads, was an open question at the time. As it turned out, the market preferred answer was "Screw it, we'll push superscalar and add more cores." But that's non-obvious in foresight. See: the famous P68/NetBurst/Pentium 4 vs P6+/Pentium M struggles.
  - klelatti 5y ago
    I broadly agree that it was non obvious and don’t really blame Intel for trying IA-64. I was really (semi humorously) trying to push back against the parent comment saying that everything these firms have done has arisen directly from customer demand. Obviously firms must think that there is demand for new products or features but sometimes they just misunderstand the market. To give another example was there really any demand from customers for x86 cores in smartphones or was it Intel just trying to establish a market presence? To answer your question iAPX432.
    - ethbr0 5y ago
      iAPX432 is a good example. :-) But in the early-80s, Symbolics was making a lot of noise with Lisp machines, the late-80s AI winter hadn't yet set in, and there were certainly worse bets than CISCy "we need to integrate up the stack" ideas. x86 on mobile is a hard one. I see why Intel did it: it's what they had. And I'm sure Microsoft was whispering some demand in their ear behind the scenes. But it really only made strategic sense pre-App Store volume (so say pre-2010?). Once the mass of code existed on ARM and built for iOS, that genie wasn't going back in the bottle. As far as I've heard it told, that was more of a financial business decision though. Intel wasn't willing to cut its margins, because it couldn't see trading volume for margin as mobile exploded. If they'd been able to offer the market cheap, sufficiently performant, power efficient chips for mobile, I think present would look a lot different.
kps 5y ago
> what information available in 1994 would have made you believe that VLIW / EPIC wasn't a viable path The i860. High peak performance on paper, realizable in approximately zero real-world code.