10 years from now, when the downfall of Intel is being taught at business schools, what are going to be the big takeways and now-obvious mistakes?
This applies to most large, inefficient corporations that get too comfy with success and forget how to pivot fast, take risks, and fiercely fight for their place in the market.
Eventually, any organization that falls into this state, slowly stagnates into oblivion.
Add to that the suspension of the dividend, and the packaging of the FPGA business (getting ready to sell it?) and the reference to idle capacity - guess they can't even fill that with their foundry business.
One thing I've noticed is that predicting timing is impossible. You can see a company showing signs of impending failure and somehow stock price still increases for a while, or the company decays slowly over a very long time. This might be a good thing since a company may save itself in some instances.
Then, eventually, you'll see a "straw that breaks the camel's back" and the hollow shell of the company will finally, fully implode.
When Jobs contacted Otellini about having Intel fab an ARM chip for them and Otellini said no... That's probably about the time their fate was sealed. And that would've been around 2006. Yes, there were plenty of signs prior to that. For example: AMD needed a lot less engineers to spin a new processor rev than Intel did and AFAIK that's still the case.
But Intel's stock has been stagnant for years.
By then:
- Intel's 10 nm node was known to be two years late and known to be plagued for many others while TSMC had already taken the crown for most advanced foundry on the planet
- Apple announced their work on phasing out Intel hardware completely for their own ARM SOCs
- AMD had launched Ryzen, back then a bit slower in single thread but already much more competitive in MT
- Supercomputers and crypto showed the ever increasing possibilities of GPUs for heavily parallelizable calculations and Intel had nothing to offer there
- Cloud providers building their own hardware on ARM
Nvidia for comparison is less than half that per year.
It is clearly not in the case or every company would have exponential growth simply by reinvesting in R&D.
In reality, it is extremely difficult to create growth from R&D at all.
Interesting that oligopsony beats oligopoly :-)
Now-obvious mistakes: I'm not including the obvious mobile argument as it belongs to the previous point, but they slept too long on GPUs. Even though the biggest supercomputers in the planet started doing computations on GPUs a decade ago they missed the ultimate parallelization-hardware train.
Honestly the problem is the same then as it was today - having good hardware isn’t enough. You need software penetration and organic usage/ecosystem. And the world can support maybe 2-3 of those right now - nvidia, apple, maybe one other. Everyone else gets the bullshit “we are the ones you need a cross-platform “adapter” ecosystems with effectively no real corporate moat etc.
(amd, intel, the door to this room is locked… one of you will get an ecosystem and the other goes home in a box… the game begins now.)
Like even just in gaming, AMD’s continued refusal to do the devrel has hurt them, it’s cost them revenue. It’s not even just “the drivers” or the constant deficit in features and functionality, but getting the people out into the studios to assist in development and tuning is how it has to be, nobody is going to tune for your hardware if you don’t do it yourself.
When their fab hit a rock with 14nm and 10nm process tech advantage was more. This gave rhe edge to all other design companies and made it clear that how behind Intel was on design front.
It makes business sense but I don't know if I like that answer. What if everyone did that? Should everyone just use TSMC? That's stupid IMO.
* Intel foundry services were perhaps a decade or two too late. Running a fab needs scale. That had to come before they lost the technology edge.
* Intel treatment and mismanagement of engineers was well-known in 2000, and you need the best and brightest.
* Leadership needs to understand core business / technology. Bob Swan. Arguably Brian Krzanich. Paul Otellini. Just a lot of clueless at the top.
Etc. The point is Intel wasn't "everyone." Intel was at the very top of the game a quarter-century ago. That was their position to lose, which they did in a spectacular fashion.
I continue to hope for a Microsoft-style comeback, but it's becoming increasingly unlikely.
I hope for a comeback too. My amateur worthless opinion is that Intel is struggling now but at least they have fabs. The fabless companies are going to be fucked in the long term- the fabs they contract to are all on shifting geopolitical sands!
It's not luck if they were riding momentum that slowed because they shifted away from proper R&D.
The fabless companies had nothing but R&D to live on and the costs of outsourcing the fab means the capital costs could be amortized over more customers (meaning intel should have probably split in two).
Intel's fabs are a generation behind and now they're capital constrained. How do you get back ahead outside of China invading Taiwan?
Can you elaborate on this?
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.
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.)
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.
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.
Funnily, the static scheduling of Itanium was the opposite direction.
> 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.
Oh, it technically could have been solved via compilers AND further architecture refinements (though it's a lesson in arrogance that Intel shunted this responsibility onto software developers). x86 is a complex mess of an instruction set, too. But it took decades of incremental hardware optimizations and compiler improvements to get it to scream. But there was a huge market for it, so anybody and everybody was working to improve it. You had everybody from big corporations to scrappy video game developers (especially John Carmack) figuring out ways to make it run faster, often via bugs in the architecture.
> 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.
I would argue that it was somewhat knowable. This wasn't the first time new CPU architectures were created. Many commercial UNIX's moved CPU architectures, some a few times. Some of their choices were similarly problematic. There were many technical and philosophical arguments on how reduced RISC processors should be.
I'm quoting from memory, but I saw a great statement somewhere that fans of RISC tended to be people forced to program assembly in university, which was painful on CISC architectures. This often clouded their judgement that extra instructions can dramatically speed up computing and the complexity can be abstracted by higher level languages and compilers/JITs. The real world is a harsh mistress (this is not to say RISC CPUs didn't have performance benefits in many cases, but it was mostly where large amounts of data needed to be computed on like databases).
> 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.
The big difference is that GPUs, which are a fundamentally different paradigm of computing from CPUs, provided an immediate improvement even before heavy optimizations could be done. GPU development was kickstarted by games and it took decades for it to branch out to other large markets (first crypto, then AI). But the real benefit of GPUs is that it didn't replace CPUs, but operated in parallel. You could even run quake without one, at obviously reduced performance.
But intel also screwed up with GPUs...
I'm a big believer in incentives. Intel's incentives were to make a CPU that nobody else could copy like x86. The complexity was probably internally seen as a benefit so it'd be harder to copy. Intel thought it could dictate to the market what it was going to get and it arrogantly saw its market domination as being stronger than it was, leaving AMD to create 64 bit extensions to x86 on its terms (hilariously most compilers call the architecture amd64).
But the biggest incentive mismatch was there was no incentive to optimize for Itanium in the market. If nobody is buying it, are you going to spend time and money making your compiler or software better for it? If you're Microsoft, how much money are you going to sink into optimizing windows, .NET, VS Code, SQL Server, etc when there's no ROI? It's also a chicken-egg problem where you can't optimize when almost nobody is using it and seeing the bottlenecks. There were no John Carmacks spending hours in a debugger trying to squeeze out performance hacks.
Meanwhile, ARM started to grow by being good at specific things at first (performance per watt at a relatively low price). This mattered first in portable devices, then moved to being important in dense datacenter environments which encouraged development of more raw performance. Now we're seeing it in top of the line consumer computers. Itanium was promised to be to be all of this at once - almost overnight. IMO it was doomed to failure the second that first sales graph was created: https://en.wikipedia.org/wiki/Itanium#Expectations. If you try to make everybody happy at once, you usually end up with nobody being happy.
I think the key difference was that in the early days, one could only afford a single-pass compiler. Then, double-pass (but it was slow). Itanium was just at the time when compilers could _practically_ do deeper program analysis.
There is no individual piece in making a good compiler for Itanium which I can't solve. At the time, most interesting CS problems that smart people were working on are what we called "microprogramming" in my college jargon -- optimizing individual algorithms, optimizing an assembly loop, etc. What made an Itanium compiler hard was (again in local jargon) "macroprogramming" -- making all those things work together.
> I'm quoting from memory, but I saw a great statement somewhere that fans of RISC tended to be people forced to program assembly in university, which was painful on CISC architectures. This often clouded their judgement that extra instructions can dramatically speed up computing and the complexity can be abstracted by higher level languages and compilers/JITs. The real world is a harsh mistress (this is not to say RISC CPUs didn't have performance benefits in many cases, but it was mostly where large amounts of data needed to be computed on like databases).
This doesn't match my history.
The hypothetical difference was the other way around. CISC had complex instructions (which might take many cycles to run, like a string copy). RISC has simple instructions. Ergo, "reduced instruction set." The technical difference in early processors was RISC was pipelined and CISC was microcode (where all instructions took many cycles).
The reason for CISC was largely so programs could be smaller. This made a huge difference if a computer has e.g. 8k of RAM. CISC, circa Pentium days, was hard to make fast because:
- CISC variable length instructions were hard to decode, and RISC fixed-length ones were easy. This mostly disappeared as decode units became smaller perhaps circa 2005.
- CISC was hard to pipeline. Again, circa 2005, it became easy to (1) avoid annoying instructions in code and treat them as very slow backwards-compatibility special cases in hardware; or (2) do a translation.
For the most part, the practical distinction disappeared around then.
> The big difference is that GPUs, which are a fundamentally different paradigm of computing from CPUs, provided an immediate improvement even before heavy optimizations could be done. GPU development was kickstarted by games and it took decades for it to branch out to other large markets (first crypto, then AI).
True. Although that's more of a business distinction than a technical one.
> But the real benefit of GPUs is that it didn't replace CPUs, but operated in parallel. You could even run quake without one, at obviously reduced performance.
I'm betting 50% on convergence, as number of CPU cores grows, and GPU cores become increasingly complex. I think the M1 may be the track we eventually converge on, with diverse cores optimized for diverse tasks.
> But intel also screwed up with GPUs...
True. Although they seem on an okay track if they can get the software right. A770 16GB can be had for $300. NVidia 4060 16GB is $450 (and faster). For a lot of non-gaming users (ML, CAD, etc.), the A770 is ideal.
> I'm a big believer in incentives. Intel's incentives were to make a CPU that nobody else could copy like x86. The complexity was probably internally seen as a benefit so it'd be harder to copy. Intel thought it could dictate to the market what it was going to get and it arrogantly saw its market domination as being stronger than it was, leaving AMD to create 64 bit extensions to x86 on its terms (hilariously most compilers call the architecture amd64).
I am too -- although that's a business rather than technical argument -- but I'm not sure that's exactly what happened here; I think it's about half-right. I think Intel simply overestimated the amount of time it would stay dominant in the market, underestimated the competition, and underestimated the time Itanium would take to develop.
I don't think they were intentionally making the CPU either easy or hard to copy.
> I think the key difference was that in the early days, one could only afford a single-pass compiler. Then, double-pass (but it was slow). Itanium was just at the time when compilers could _practically_ do deeper program analysis.
> There is no individual piece in making a good compiler for Itanium which I can't solve. At the time, most interesting CS problems that smart people were working on are what we called "microprogramming" in my college jargon -- optimizing individual algorithms, optimizing an assembly loop, etc. What made an Itanium compiler hard was (again in local jargon) "macroprogramming" -- making all those things work together.
Both these circle back to a point I made earlier in the thread - who’s going to do that for a processor nobody is using? There is an alternate timeline where a combination of hardware and compiler/software iteration make Itanium competitive at a performance level, but intel’s non-technical decisions made that impossible at a practical level. It was never made cheap or available enough where anybody could tinker at the lower end, and at the high end they suffered from the chicken/egg “nobody bought it because x86 was faster today”.
The Itanium did to very well in some supercomputer deployments where the code could handle the architecture’s good parallelism. But that was likely net-new code for a niche product.
> The hypothetical difference was the other way around. CISC had complex instructions (which might take many cycles to run, like a string copy). RISC has simple instructions. Ergo, "reduced instruction set." The technical difference in early processors was RISC was pipelined and CISC was microcode (where all instructions took many cycles).
Hypothetically, yes. In the real world a lot of work was done to minimize that over x86’s lifetime. In the early days RISC did do a lot of what was promised, but clever (some would say hacky in some situations) updates to x86 CPUs and compilers made these advantages less (although one could argue the x86 microarchitectures that showed up in the mid to late 1990s were more RISC like). Faster and better caching (variable length x86 instructions meant that common instructions can have a shorter encoding and take up less space in the instruction cache, vastly reducing expensive cache misses) also minimized a lot of these issues. The main issue was a lot of these “enhancements” kept the performance per watt ratios at very poor levels, which caused no end of headaches as laptops became more popular and left intel (and AMD with x86) with no competitive alternative to ARM in phones.
> The reason for CISC was largely so programs could be smaller. This made a huge difference if a computer has e.g. 8k of RAM. CISC, circa Pentium days, was hard to make fast because: > - CISC variable length instructions were hard to decode, and RISC fixed-length ones were easy. This mostly disappeared as decode units became smaller perhaps circa 2005. > - CISC was hard to pipeline. Again, circa 2005, it became easy to (1) avoid annoying instructions in code and treat them as very slow backwards-compatibility special cases in hardware; or (2) do a translation.
I agree with all these points, but even before the decode enhancements ~2005, lots of work was done to mitigate these. But the most obvious thing that x86 caught up with was clock speed. A central argument in favor of RISC was that it allowed for an ability to jack up the the clock speeds of processors, that could then iterate over the reduced instructions faster and provide better performance in most computing cases. This clock speed advantage (in practice) was eliminated, though not due to issues with RISC itself, but more because it was only the large volumes of x86 chips could justify the higher costs of staying near the bleeding edge of transistor manufacturing allowing smaller transistor sizes (something that ARM would eventually come to lead, though).
The CISC instructions were often heavily improved upon over hardware iterations or moved over to new ones (MMX being a famous example) that were more in line with how code was used (hilariously MMX became kind of redundant soon after as GPUs took over those functions). There were also many cases where x86 could do things in fewer instructions than RISC, which helped even more at higher clock speeds as x86 caught up.
Again, I’m not necessarily defending CISC/x86. But it had so much engineering heft thrown at it due to its install base that it often brute forced its way to performance and it was only when performance per watt metrics started to matter that an alternative came on the scene (and it was not something that Itanium would have been better at - ARM would probably be causing the same issues to intel in the data center had Itanium taken off as it was). This was always going to be a hindrance to any replacement. The fact there was genuine competition in x86 kept prices lower and development cycles active, too.
A lot of what you state is correct, but in practice x86 chips were still faster for most workloads out there. In a perfect world all this time and effort would have been heaped on a far better CPU architecture (CISC or RISC), but alas…
Even today x86 still outperforms ARM on most server chips, but our AWS loads are using their ARM chips because it’s cheaper per unite of compute, which is fine for most workloads. This may even get better as more focus is put on ARM via compilers or architecture iterations.
> True. Although that's more of a business distinction than a technical one.
It’s a technical one. They provided immediate technical enhancements, but didn’t mean all your current code had to be rewritten. It was optional (until video games got so sophisticated that they were required then) and you didn’t need to rewrite/recompile your OS to use it. However, GPUs are a lot more niche, so fundamental architecture changes can be done more easily, especially as most code out there is done via higher level APIs.
> I'm betting 50% on convergence, as number of CPU cores grows, and GPU cores become increasingly complex. I think the M1 may be the track we eventually converge on, with diverse cores optimized for diverse tasks.
I agree on this for most consumer products. SoCs have taken over the embedded and mobile market and that can continue to other markets. But we’ll see what happens if AI continues its current trajectory. There it’s the GPUs that matter more than the CPUs and we could see something different emerge.
> I am too -- although that's a business rather than technical argument -- but I'm not sure that's exactly what happened here; I think it's about half-right. I think Intel simply overestimated the amount of time it would stay dominant in the market, underestimated the competition, and underestimated the time Itanium would take to develop.
It’s all about business, though. If the world was purely technical, Amiga, DEC, or Sun would be on top of the world. Intel did everything you just said, but also tried to do too much. A lot of what intel does is over-engineered in a sense they do things in a more complex way that necessary (some cynical people would say on purpose to make larger margins on hardware/chipsets eg USB, which at a low level is very complex even for the original spec).
> I don't think they were intentionally making the CPU either easy or hard to copy.
At an engineering level, no. But higher up they made sure the way it worked with IP, etc would make this difficult. The fact that x86 clones exist at all was a legal miracle and a quirk of history (pretty much IBM demanding it for the original PC and intel was not big enough yet to say no): https://jolt.law.harvard.edu/digest/intel-and-the-x86-archit...
> In the real world a lot of work was done to minimize that over x86’s lifetime. In the early days RISC did do a lot of what was promised, but clever (some would say hacky in some situations) updates to x86 CPUs and compilers made these advantages less (although one could argue the x86 microarchitectures that showed up in the mid to late 1990s were more RISC like).
They were identical to RISC architectures, with the exception of a more complex decode unit, which led to extra transistors burning extra power and costing speed in the early Pentium days.
That mattered a lot when a 1993 Pentium had 3.1 million transistors.
That matters a lot less when a modern Intel CPU has ≈5 billion transistors.
Fundamentally, that's what allowed x86 to pass all the various RISC architectures in speed. Those kinds of differences in instruction set just don't matter anymore. At that point, it was just R&D dollars, which Intel had more of due to volume.
As a footnote: It's worth remembering StrongARM. The SA-110 was just as fast as the fastest Intel had to offer, when introduced in 1995, at a much lower price and power budget. It was crazy I could get a little embedded board for $100-$300 which was just as fast as $5000 computers. Intel acquired it from DEC. Oddly enough, it barely improved from there on. A decade later, clock speed went up 4x on the XScale (and only on the very top-end), and more than 15x on the x86.
The fabless companies will also have a problem if only TSMC is left. What is there to keep them from rising the prices? Right now TSMC is afraid of Samsung and Intel, but if Samsung falls behind and Intel folds, AMD / NVDA / ... will have a crisis on their hands.
The US leadership fucked the dog and decided cheap labor was more important than national security or a functioning economy.
Everything is gone, it has been shipped overseas.
Organized labor is considered a threat to national security, it's no coincidence that deindustrialization followed a period of widespread labor militancy.