Both Intel and Microsoft made some kind of categorical error in 1995-2005 in assuming that their dominance was tied to a particular programming interface. Intel clung to the x86 instruction set while Microsoft operated on a “Windows everywhere” mindset, first pushing Win32 and then .Net.
Wintel seems finally dead, and good riddance.
Itanium launched in 2001 (per Wikipedia); if anything, I'd say they overestimated how readily they could ditch x86. Of course, it might be that replacing x86 was a good idea and it was just that Itanium sucked (I'd accept that possibility, given the whole "needs a smarter compiler than exists" thing). But I do agree with the general feeling that Intel and MS both overestimated how solid/entrenched they were.
However, when AMD released AMD64 it killed this strategy. You could now buy a chip that natively ran x86 32 bit at full speed, plus be able to run code that could address more than 4 GB of RAM.
Once AMD64 came out, Itanium was a dead architecture.
[0] https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90...
This means that there is some hardware that checks condition that will not happen during normal course of events - compiler won't generate such code and write to register that reads zero is harmless.
That hardware stays there, occupies space (does not matter how little) and drains energy (no matter how little).
This part of hardware is utterly meaningless and shows how priorities were skewed during design phase. It also shows why Itanium was such a bad chip - features were piled up instead of being cut down.
RISC-V did cut down on features first (compare division overflow in RISC-V and OpenRISC) and has a process to add them. This is why RISC-V is easy to implement even in OoO variant and why it is being picked up by everyone and their dog.
You mean 64 GB limitations? 32-bit x86 could handle that much, and I'm sure it would have without AMD64.
All in all, not ideal, but I'm sure we would have managed with it a bit longer.
[0]: https://en.wikipedia.org/wiki/Address_Windowing_Extensions
The downfall of the Itanium had several reasons. They went beyond RISC with EPIC, a technology which had great theoretical promises, but had not been shown to yield those results in practise. Also, the project suffered from bad management and delays. Finally AMD pushed x86 just far enough forward to be a viable alternative.
In the beginning, the Itanium was an expensive, power-hungry monster, but it did perform quite well for heavy computations. It could have had a much better future, if Intel had not abandoned it - the software situation could have been much better, if for example Linux boards had been made available to all interested. The latest version only made it to a 32nm process, the transistor count being smaller than in a modern iPhone. So just redoing the same design in a cutting-edge process would make for a very interesting processor.
Intel misjudged both sides, for phones x86 compatibility was never necessary, for business machines, it absolutely is (for the largest number of customers, there have been exceptions).
HP saw the disaster coming and designed their own McKinley Itanium, but a bit later, and HP obviously didn't want Dell to have it.
The compiler support was not good outside HP-UX, if I remember correctly.
And then AMD64 happened, and Microsoft told Intel that there would be no further 64-bit PC instruction sets, and the market would choose between AMD and Itanium.
Cue the guillotine.
Non trivial amount of know-how and - if rumours to be belied[1] - direct design then went from Alpha team at Compaq to AMD, though Intel retained some of it (AMD already had been doing cooperation with Alpha, leading to the funky case of "jig it enough and an Athlon-MP motherboard might just run an Alpha and Athlon at the same time").
[1] - Once heard from semi-reputable source that an early K8 changelog entry contained "dropping support for VAX floating point formats". Unverifiable unless someone somehow publishes those docs, but it did fit with "That opteron looks suspiciously similar to EV7"
it sounds interesting
Intel should have known this, but you buy processors because they are faster or cheaper. These days the third rail is energy but it’s basically the same, if you pay more you want a lot more and “Different” costs. Itaniums where a whisker faster than their ia32 offerings at the time, they cost a lot more though, and they were different. Beyond that, it was like a geek designed the specs with out a market story, risc chips were coveted by x86 dorks because they had 32 registers to the x86’s 5 or 6, well ia64 had 128... If you’re just doing simple stack frame compiler work without full program optimization, how many functions need 32 registers? Let alone 128? everyone could see that you wanted to simplify things in order to put silicon where it mattered for longer term performance, mid to late 90s reordering conditionals for branch prediction was sort of hot in compiler dork and low level circles, well Merced fixed that by adding a lot of complex logic to take both branches and retire the wrong one. IBM, HP and Sun needed different reliability and serviceability features on their high end systems too, from the big enterprise metal perspective they were toy parts for PCs, but they cost more, didn’t run your existing software and weren’t 2x faster or anything like that. They didn’t take a holistic market view as they made it. Rather than work with ibm, sun and hp on those high end issues, they just went back to the lab and told them when the first parts would be out.
Not really sure what goes on inside intel, they have a lot of brilliant people. I suspect that they cannibalize themselves because nothing will ever be as successful as the x86 was when they owned every aspect of the part and package and things are decided to be a failure before they ship. With ia64 nobody asked why. Xeon phi, they gpu and machine learning stuff reflects that too.
As I understand it, these were influenced by SuperH, a 32-bit RISC design that uses 16-bit instructions, so two are always executing at once.
The busybox-armv7m Thumb2 binary is the smallest of all the compiled architectures.
Thumb2 appears to have been much more practical.
Actually their judgement there was correct. There dominance absolutely was tied to monopoly power, via "particular interfaces". Working on alternatives would have undermined the monopoly.
They error was thinking the monopoly wouldn't have eventually been undermined anyways. They upped the risk for more reward, and got bit.
This incidentally is another reason why monopolization is bad: even when it doesn't last indefinitely, it makes for shitty companies that refuse or cannot adapt, and will be stubbornly stick to their ways until more sudden failure. Stagnation and then a jolt is less growth, and irrespective of growth bad for society. No government should want this.
> In fact, Intel pointed out to me in the wake of the article’s publication that it possesses an ARM architectural license, the highest level of relationship with the British intellectual property (IP) licensing firm, which Intel retained when it sold its communications product line to Marvell in 2006.
Given the resulting impact (Intel being far behind in the smartphone market), it might qualify as the costliest Excel error of all time.
>At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."
https://www.theatlantic.com/technology/archive/2013/05/paul-...
If Intel managed to convince Apple to go x86, and they had low power chips competitive with ARM at the time, then that would be a different story.
You could even argue that it was a happy accident; Intel providing a high performance ARM core may have forced mobile competitors to react, producing high performance ARM chips of their own, and sped up the erosion of the x86 monopoly we're finally witnessing today by several years.
I doubt TSMC would have been able to afford to catch up to Intel without their current high volume business.
Apple pursued custom silicon very aggressively from the start, with the acquisition of PA Semi less than a year after the launch, and the first custom chip coming in the iPad in 2010.
Although with an Intel chip they wouldn't have needed to do this for performance reasons, Intel's fat gross margins would have been equally compelling.
If Intel was willing to design the chips and take TSMC sized margins on them, I guess they could have kept the iPhone business for years, but that isn't in their DNA.
I can't see Intel ARM iPhone chips as anything other than a shortly lived oddity.
By sending all that business to TSMC and Samsung, they were financing their rival's R&D.
If they were willing to do that, I totally buy in to your scenario. It would have been the right play with the benefit of hindsight.
But it would have represented the biggest shift in their business model since they dropped DRAM. Just agreeing to fab the iPhone 1 CPU wouldn't have been nearly enough.
>It was the only moment I heard regret slip into Otellini's voice during the several hours of conversations I had with him. "The lesson I took away from that was, while we like to speak with data around here, so many times in my career I've ended up making decisions with my gut, and I should have followed my gut," he said. "My gut told me to say yes."
https://www.theatlantic.com/technology/archive/2013/05/paul-...
Keep in mind that they didn't quit their Xeon Phi strategy until 2017, four years after that interview. The parallels are strong.
It's an equally valuable market to mobile, but they weren't willing to get their hands dirty, build a commodity GPU, and either a CUDA bridge ala ROCm or concerted effort on bringing OpenCL up to speed.
Instead, they tried for a decade to bring x86 to GPGPU, not for any technical advantage, but because if they can make it stick they can be an (at worst) duopolistic vendor.
They started with in order cores little better than a Pentium with massive vector units, and progressively improved them to Atom cores once it became clear how much work you'd have to do to port legacy x86 code on to them, at which point why not just port to CUDA?
Now the Xeon Phi torch will be passed to... absolutely standard Xeons with HBM. And they're building that general purpose GPGPU, but it's going up against a version of CUDA that's had a decade longer to mature and a nVidia with 102% of their market cap, instead of 9.9%.
The reason for this insanity is Intel realized just how profitable monopolies are, and they're willing to make risky (almost stupid) bets in the hope that they'll yield their next one. They're searching for the home runs with little enthusiasm or staying power for anything else.
This is the Intel I know, and it's not the kind of Intel that's willing to take crappy gross margins to fab commodity ARM chips. It's the kind of Intel that's going to try to do everything in its power to cram so very out of place Atom processors in to mobiles in the vein hope they'll catch on through a combination of incentives and temporary consumer insanity.
Which is exactly what they did try instead of the ARM thing, from 2008 to 2016. RIP.
If Intel did make ARM CPU for the original iPhone and other early mobiles, it would have followed the same trajectory as Intel's original SSDs. They'd be years ahead of their competition at launch, but left to stagnate as the rest of the market catches up, once Intel realizes they're actually going to have to work for their money with no sustainable advantage.
- He's probably flat-out lying, poopooing the data driven stuff to come off more human, humble, and sympathetic to the interviewer.
- If the numbers really did say they should stick to their monopoly, huge extra revenue be damned, then this is some model the FTC and "...but consumer prices!" crowd needs to be forced to grapple with.
Even Microsoft proved that they could build a featurific program without .Net, in VSCode. It’s an electron and JavaScript application. And, they were able to make it run everywhere.
Worth pointing out the two directional changes That Intel made, from DRAM to Microprocessor and IA64, NetBust High Clockspeed to Pentium M IPC. The first one was Andrew Grove, the 2nd one was from his disciple Patrick Gelsinger.
Those people are gone. Retired or pushed out by Intel's politics. Their legacy and work continues for about 5 years, as that is the lead time of their roadmap. And we saw what happen to Intel since 2016.
The problem is that Intel no longer has the leading state of the art fabs. They used to be two generations ahead of everyone else, and now they're two behind. The inertia of x86 has kept them afloat, but the longer Intel fabs lag the more ground ARM has been able to make up.
Intel fabbing ARM parts isn't going to do them much good unless they also manage to get their process shrink delays worked out and behind them.
There's been some suggestions to replace node size claims with better density metrics https://ieeexplore.ieee.org/document/9063714. It's not like TSMC's fabs are some order of magnitude more advanced than Intel's fabs. If Intel had an ARM chip to produce today they could use their considerable fab volume to produce them profitably. Even at large process sizes they could still produce competitive ARM chips. It's not like their current x86 chips at 14nm are slouches.
Except that everybody seems to forget that Apple's ARM chip isn't commodity.
Apple is going to tune their ARM specifically to run portable workloads. For starters, they're going to have humongous caches that make the chips expensive.
And they're going to bury the expensiveness of the chip in the enormous margins of iDevice ecosystem.
Apple isn’t going to release chips that benchmark slower than the Intel equivalents. To sell the transition they’ll need to say something simple like “2X faster” on the big screen. So I expect to see 8+ core chips as standard even if they don’t need that many to deliver a good product.
The question is whether such a chip would be cheaper for Apple.
The interesting question is going to be how Apple's GPU stacks up to the competition. We know from the A13X that it is already quite good and I fully expect it to exceed Intel embedded graphics. But what about higher end machines? How long till Apple GPUs can take the fight to discrete graphics?
https://developer.apple.com/videos/play/wwdc2020/10686/
I'd be surprised to see discrete graphics in anything below an ARM iMac/iMac Pro.
My bet is that for the iMac & MacPro, Apple will use custom AMD on-die GPUs (like the now discontinued Kaby-Lake G). They just haven't announced it yet and AMD seems to be silent about it. I also bet the demo they showcased of Rise of the Tombraider was running on such an unannounced custom chip.
I you think about it, it doesn't make much sense for Apple to enter the highend segment for GPUs and sink a significant amount of research cost into it. What they need is power-efficient GPUs for their mobile line (iPhone, iPad, Macbook Air & low end Macbook Pro) so that is where an all-Apple GPU design will be used. But for professional high end use, they will not be in the position to ship a GPU (no matter if on-die or discrete) that could compete with AMD or Nvidias performance hogs out of nowhere.
Market share for high-end Macbooks + iMac + MacPro is just too little given their overall product portfolio (including mobile devices) and the research effort too high. Also, AMD would probably happily design them a custom GPU chip for on-die usage, just as they do for consoles and did for the Kaby Lake G. It wouldn't hurt AMDs business, even if Apple plans to replace AMsD with custom all-apple based GPUs in the long run (i doubt it), as it is very unlikely Apple will ever license it to other CPU vendors or even enter the market for discrete GPUs for Wintel machines.
I already play Fortnite, Call of Duty, PUBG, etc at 60fps on my iPhone.
For them to not do this would be strange.
Arguably the r&d costs would still exist for just their iPhone line. And I’m sure the cost to add a Mac line isn’t as much as the intel premium
Literally everyone has humongous caches. In fact Intel cache architectures are far larger and more elaborate than anything on an Apple chip.
Did they have such competition in the past, plus their main market (desktop) becoming irrelevant and mobile (and maybe server) going to another CPU?
So Intel's got the income to make big shifts. There's also enough momentum of continuing x86 sales that their revenue from them won't dry up immediately if they did start building ARM chips.
I don't think absolute numbers are what matters. For a company in the stock market, the fact that mobile has grown 10x the size of desktop sales, where the desktop has become stagnant means they lost big on a market...
While they could be a player in the smartphone CPU market it's not like they had it tied up and lost it. Intel's real challenge now is recognizing that the desktop/laptop and server markets are no longer guaranteed sales for them.
Is a developer in this context a third party who goes out and licenses the different IP Cores for a customer and then designs a chip using them for that customer? If so I'm curious why would someone use a third party developer over ARM itself? Who are some of the bigger ARM developers today?
Historically this seems to be the case most of the time. Market leaders miss the next iteration of their industry. The "Innovators Dilemma" is ever present.
"This 'telephone' has too many shortcomings to be seriously considered as a means of communication. Western Union internal memo, 1876.
ex-ARM employee here.
Also Intel clearly has some sort of license that covers modern cores as well, given it manufactures FPGA's with various newer ARM cores based on its purchase of Altera.
These days, I think you’re right with the possible exception of density: if you have comparable resources, vector extensions, etc. an ISA which uses memory more efficiently is going to get a little more out of its cache and memory bandwidth, but that’s probably not going to be huge.
They've managed to change direction in the past. They were all-in on Itanium and NetBurst until the Opteron showed up. They then kicked both to the curb and went all-in on the Pentium-M/Core microarchitecture.
Intel would be foolish to ignore the ARM market if for no other reason than the server market has started to change their focus on ops/watt rather than just ops/dollar. A 64 core ARM uses less power than a 64 thread Xeon with comparable performance.
That means the lifetime cost of that ARM chip will be much lower than the Xeon since it'll cost less to power and cool it (and the datacenter). Lower power requirements can also change the calculus of datacenter siting.
I don't see Intel getting to ARM ops/watt levels with their x86 designs. The Lakefield designs are promising but the "big.LITTLE" core configuration is more useful in mobile applications than servers.
Intel losing out to ARM designs is really Intel's choice at this point.