13 ms·

>they shifted away from proper R&D. Can you elaborate on this?

hylaride 2y ago
I should elaborate on the word "proper" in this context. Intel rarely had the best technology, but it was often "good enough, cheap enough, and available enough" to succeed in the marketplace - this is a lesson SO MANY people forget. Sun, DEC, etc arguably had better hardware, but it was expensive. What Intel was very good at was iterating on the technology it had and making it faster within a reasonable budget. Microsoft is another good example of where "good enough, cheap enough, and available enough" is what usually matters in the market. Where they started to stumble is when they got greedy. The whole RAMBUS debacle back in the day is a good example of where they took more expensive and worse RAM and tried to make it mandatory. Then there was the whole Itanium debacle, where politics succeeded over engineering and they ended up with a worse, more expensive product that failed in the market. AMD, which had recently acquired a lot of talent from DEC's alpha chip design, then went on and made 64-bit extensions to x86 that Intel had to play catch up to. Intel (for the most part) ignored the performance per watt aspect of CPU design, which mattered in embedded, mobile, and dense datacentre environments. The result is that ARM came from the bottom up and is now eating Intel's lunch from all angles. Intel's fabs couldn't compete with TSMC and to a lesser extent Samsung, both of whom could focus on the intense CAPEX (which due to cultural reasons people in Asian countries are willing to take longer term outlooks). CAPEX looks bad on an american GAAP spreadsheet. TSMC literally could take upfront money from apple to build new state of the art fabs and guarantee them a certain number of chips (and keep the money if the iphone had failed in the market). Intel couldn't do that. Intel spent most of the 2000s era doing $130B in stock buybacks and even if it was run by engineers, they lost sight of the market. Stock buybacks and dividends are fine if you have surplus cash, but chip design is a high CAPEX business.
- AnimalMuppet 2y ago
  > Then there was the whole Itanium debacle, where politics succeeded over engineering and they ended up with a worse, more expensive product that failed in the market. Why do you say Itanium was politics over engineering? It turned out to be a not-really-workable idea, sure. But if you looked at it, not knowing how it was going to work out, it was not an obviously bad idea. It was probably worth trying. (Or are you saying that politics succeeded over engineering in the process of implementation of Itanium? I have no view on that.)
  - hylaride 2y ago
    I’m saying the latter, that politics succeeded over engineering in the process of implementation of Itanium. The instruction set for it was relatively bloated, indicating that there were too many compromises being made. Writing compilers for it was a notorious shitshow. Itanium introduced a too much of indeterminism by via static scheduling hostile methods like branch prediction, variable latency caches, and attempts at an x86 compatibility layer. The core problem for Itanium is that it was impossible for the compiler to make good calls since it could not know exactly where and when things in memory would be. Even intel’s own compilers produced lackluster results, to say nothing of attempts by Microsoft, HP (who bet the farm on Itanium), and GNU (which mattered for Linux). There were politics and demands from HP, which was the only seriously committed partner that wanted chips that would in theory be best for replacing pa-risc, but then intels own expectations of having it replace x86 everywhere. Itanium actually did perform well at some kinds of parallelism. However, to take full advantage of that would have required a paradigm shift in the way languages worked, because 99% of the code out there was sequential/procedural. So maybe some new code (or more likely languages) could have really kicked ass (and intel did demonstrate that was possible), but even if everybody decided to go ahead there’d be a lot of learning and mistakes on the journey to full optimisation. Or you could just make your current code go faster by buying cheaper 64 bit x86. I could go on, but you get the idea.
    - frognumber 2y ago
      My recollection at the time was that there were good reasons to believe compilers would be workable. We were in the golden years of Java bytecode translations, real-world JITs, and Transmeta (which made a similar bet in hardware). That was the era we were starting to introduce rather complex transformations and optimizations. Computers were just starting to become powerful enough to where this kind of analysis and optimization felt possible and practical. The compiler problem felt complex, but not unsolvable. There were no good, obvious reasons I recall why the Itanium optimization problem couldn't be solved. The basic philosophy was make the hardware as fast as possible, even if it was hard to program, just rely on the compiler to deal with it. Now, in hindsight, I can give all the reasons it didn't work. Key among them is that we drastically underestimated the degree to which complex software systems are hard to build and the way code messiness grows exponentially for these kinds of systems. However, that wasn't really knowable in hindsight, though. Around the time, a lot of firms were making similar bets, and in 2001, I likely would have made the exact same bet with what was known at the time. As a footnote, the anticipated progress in compilers is being made, but much more slowly than anticipated. NVidia reached its market cap on architectures being explored at that time. I had plenty of faculty promise similar SIMD/MIMD architectures would be increasingly important, but __dramatically__ underestimating the time it would take to get there.

I should elaborate on the word "proper" in this context. Intel rarely had the best technology, but it was often "good enough, cheap enough, and available enough" to succeed in the marketplace - this is a lesson SO MANY people forget. Sun, DEC, etc arguably had better hardware, but it was expensive. What Intel was very good at was iterating on the technology it had and making it faster within a reasonable budget. Microsoft is another good example of where "good enough, cheap enough, and available enough" is what usually matters in the market. Where they started to stumble is when they got greedy. The whole RAMBUS debacle back in the day is a good example of where they took more expensive and worse RAM and tried to make it mandatory. Then there was the whole Itanium debacle, where politics succeeded over engineering and they ended up with a worse, more expensive product that failed in the market. AMD, which had recently acquired a lot of talent from DEC's alpha chip design, then went on and made 64-bit extensions to x86 that Intel had to play catch up to. Intel (for the most part) ignored the performance per watt aspect of CPU design, which mattered in embedded, mobile, and dense datacentre environments. The result is that ARM came from the bottom up and is now eating Intel's lunch from all angles. Intel's fabs couldn't compete with TSMC and to a lesser extent Samsung, both of whom could focus on the intense CAPEX (which due to cultural reasons people in Asian countries are willing to take longer term outlooks). CAPEX looks bad on an american GAAP spreadsheet. TSMC literally could take upfront money from apple to build new state of the art fabs and guarantee them a certain number of chips (and keep the money if the iphone had failed in the market). Intel couldn't do that. Intel spent most of the 2000s era doing $130B in stock buybacks and even if it was run by engineers, they lost sight of the market. Stock buybacks and dividends are fine if you have surplus cash, but chip design is a high CAPEX business.

AnimalMuppet 2y ago
> Then there was the whole Itanium debacle, where politics succeeded over engineering and they ended up with a worse, more expensive product that failed in the market. Why do you say Itanium was politics over engineering? It turned out to be a not-really-workable idea, sure. But if you looked at it, not knowing how it was going to work out, it was not an obviously bad idea. It was probably worth trying. (Or are you saying that politics succeeded over engineering in the process of implementation of Itanium? I have no view on that.)
- hylaride 2y ago
  I’m saying the latter, that politics succeeded over engineering in the process of implementation of Itanium. The instruction set for it was relatively bloated, indicating that there were too many compromises being made. Writing compilers for it was a notorious shitshow. Itanium introduced a too much of indeterminism by via static scheduling hostile methods like branch prediction, variable latency caches, and attempts at an x86 compatibility layer. The core problem for Itanium is that it was impossible for the compiler to make good calls since it could not know exactly where and when things in memory would be. Even intel’s own compilers produced lackluster results, to say nothing of attempts by Microsoft, HP (who bet the farm on Itanium), and GNU (which mattered for Linux). There were politics and demands from HP, which was the only seriously committed partner that wanted chips that would in theory be best for replacing pa-risc, but then intels own expectations of having it replace x86 everywhere. Itanium actually did perform well at some kinds of parallelism. However, to take full advantage of that would have required a paradigm shift in the way languages worked, because 99% of the code out there was sequential/procedural. So maybe some new code (or more likely languages) could have really kicked ass (and intel did demonstrate that was possible), but even if everybody decided to go ahead there’d be a lot of learning and mistakes on the journey to full optimisation. Or you could just make your current code go faster by buying cheaper 64 bit x86. I could go on, but you get the idea.
  - frognumber 2y ago
    My recollection at the time was that there were good reasons to believe compilers would be workable. We were in the golden years of Java bytecode translations, real-world JITs, and Transmeta (which made a similar bet in hardware). That was the era we were starting to introduce rather complex transformations and optimizations. Computers were just starting to become powerful enough to where this kind of analysis and optimization felt possible and practical. The compiler problem felt complex, but not unsolvable. There were no good, obvious reasons I recall why the Itanium optimization problem couldn't be solved. The basic philosophy was make the hardware as fast as possible, even if it was hard to program, just rely on the compiler to deal with it. Now, in hindsight, I can give all the reasons it didn't work. Key among them is that we drastically underestimated the degree to which complex software systems are hard to build and the way code messiness grows exponentially for these kinds of systems. However, that wasn't really knowable in hindsight, though. Around the time, a lot of firms were making similar bets, and in 2001, I likely would have made the exact same bet with what was known at the time. As a footnote, the anticipated progress in compilers is being made, but much more slowly than anticipated. NVidia reached its market cap on architectures being explored at that time. I had plenty of faculty promise similar SIMD/MIMD architectures would be increasingly important, but __dramatically__ underestimating the time it would take to get there.