An Interview with Intel CEO Pat Gelsinger(stratechery.com)
stratechery.com
An Interview with Intel CEO Pat Gelsinger
https://stratechery.com/2022/an-interview-with-intel-ceo-pat-gelsinger/
36 comments
I'm not sure focusing on the instruction set is the right angle.
x86 would be more competitive in the mobile space if Intel had offered efficient chips. Is the instruction set the biggest blocker that prevented this? Or is it the licensing model? Perhaps if Intel had licensed their architecture and instruction set to others, like ARM does, they would be in a better position?
ARM's licensing model get's a lot more eyes on instructions sets and chip designs. It allows big companies like Apple come in and run the show, licensing just the instruction set. Why wasn't Intel working with large customers with an interest in custom x86 designs? In hindsight it seems presumptuous to assume there is no x86 talent outside Intel/AMD.
Really impossible to know how much the actual instruction set is holding Intel back without being on the inside.
x86 would be more competitive in the mobile space if Intel had offered efficient chips. Is the instruction set the biggest blocker that prevented this? Or is it the licensing model? Perhaps if Intel had licensed their architecture and instruction set to others, like ARM does, they would be in a better position?
ARM's licensing model get's a lot more eyes on instructions sets and chip designs. It allows big companies like Apple come in and run the show, licensing just the instruction set. Why wasn't Intel working with large customers with an interest in custom x86 designs? In hindsight it seems presumptuous to assume there is no x86 talent outside Intel/AMD.
Really impossible to know how much the actual instruction set is holding Intel back without being on the inside.
The problem is that the revenues from those licenses would be so much lower than the margins on those x86 CPUs to make it almost impossible for Intel to switch. Apple moving Macs to Arm has given better performance __and__ lower prices.
I do think that Intel has executed badly on the ISA front too. Let’s not forget that x64 wasn’t an Intel design (how much did they spend on Itanium) and they’ve messed around with AVX-512 which just seems to eat die area and power.
By contrast Arm managed to get its customers switched over to 64 bit seamlessly and has left most of their awkward legacy behind.
I do think that Intel has executed badly on the ISA front too. Let’s not forget that x64 wasn’t an Intel design (how much did they spend on Itanium) and they’ve messed around with AVX-512 which just seems to eat die area and power.
By contrast Arm managed to get its customers switched over to 64 bit seamlessly and has left most of their awkward legacy behind.
true. but I really cant imagine that the area and latency associated with the uop translator is really where this is all falling down. i have always wondered how much support for the old vector units, segmentation and all the rest cost, but it cant really be that much since caches keep getting bigger and bigger. its a really good question.
There are other costs that either make very wide OoO more difficult or more costly. x86 has a lot more flag-based instructions compared to Arm. That adds more dependencies that the reorder engine has to sort through. x86 variable length decoding takes log(n) in decode circuit depth, which either forces a longer pipeline or limits clocks. And obviously AVX512 units are just huge because a decision was made to make them the same latency as normal MUL/ADD/FMA. And x86 designs have to scale in clockspeed from server / tablet (~2.5GHz) to desktop and high perf laptop (5GHz+). That forces suboptimal designs like the 5 cycle L1 in Golden Cove. Meanwhile Apple has a 3 cycle 192kB L1.
Yeah I think this is all valid - i really mean it more as a product line and the lack of practical substitutes before recently (especially on the server side), not the specific details of the instruction set v others. They were basically the only game in town for a while. Had they licensed it, yep, it would have been different.
It’s a classic innovator’s dilemma- they can continue milking the x86 or reinvent the company but not both at the same time.
> but not both at the same time.
For 20 years they could have afforded to. Now it may be too late. If they try I don’t think the market would punish them for it.
And in fact they are famous for killing their cash cow (memory) and focusing on the new thing (microprocessors) in the 80s under Grove. They have fallen far.
Other big companies, like Google, have this problem and haven’t made efforts to address it.
For 20 years they could have afforded to. Now it may be too late. If they try I don’t think the market would punish them for it.
And in fact they are famous for killing their cash cow (memory) and focusing on the new thing (microprocessors) in the 80s under Grove. They have fallen far.
Other big companies, like Google, have this problem and haven’t made efforts to address it.
Intel is not going to beat anyone else in architecture or design in any compute system besides x86. They don't have the experience, the talent, or the culture to do so. Heck, Intel can't even beat AMD in x86 power/perf. So Pat is just stating the obvious, Intel has no option but to go maximal x86.
Yep, I'm not even saying he's making a mistake. Every option looks problematic and his choice might well be the least bad option.
If Microsoft managed to do turn around, then why they cant?
> Some of these conversations, Ben, I just find them delightful. We have these five whale customers that we’ve talked about, these are active conversations. Active, daily things and in that, the teams are now saying, well, what about the ultra low voltage threshold for the thin pitch library that we’re going to use in this particular cell? “TSMC is giving us these characteristics, you don’t characterize that corner.” Okay, guess what? Go characterize the corner! “Your PDK isn’t as robust as the Samsung or TSMC PDK is to describe the process technology for my team to simulate.”
I get where he's going with this but if you're ever on the other side interacting with a vendor you should be very careful about what, if at all you disclose that their competitors are doing. Vendors notice what they learn from your teams and if they know it is leaky they will not disclose things that make the technical side easier.
At a past gig we used the be the central point of contact for our vendors because we kept a strict firewall on the technical side between different product lines and SoCs.
The first instinct of most engineers when you're trying to evaluate something or get the best performance is to say "X does Y, why don't you do Y" or "X does Y, how can we get similar results" and you've just disclosed something and that vendor will notice. On the flip side if you build up that trust and are known to not disclose you can be read in on things that normally wouldn't be shared. This can be incredibly valuable when you're trying to close on a key technical issue under schedule/time constraints.
I get where he's going with this but if you're ever on the other side interacting with a vendor you should be very careful about what, if at all you disclose that their competitors are doing. Vendors notice what they learn from your teams and if they know it is leaky they will not disclose things that make the technical side easier.
At a past gig we used the be the central point of contact for our vendors because we kept a strict firewall on the technical side between different product lines and SoCs.
The first instinct of most engineers when you're trying to evaluate something or get the best performance is to say "X does Y, why don't you do Y" or "X does Y, how can we get similar results" and you've just disclosed something and that vendor will notice. On the flip side if you build up that trust and are known to not disclose you can be read in on things that normally wouldn't be shared. This can be incredibly valuable when you're trying to close on a key technical issue under schedule/time constraints.
I find "X does Y, why don't you?" As a means to keep vendors from becoming complacent. As customers, we don't know what the tools limits are. Sometimes, vendors will not invest in improving their tools/results without a credible threat. The results from competing vendors is the closest you can get to impartial results that create pressure to perform.
I think that is a reasonable counter argument to the solid advice GP shared. In my experience, vendors are usually well aware of their competition. It’s a thin and subtle line between motivating them and recklessly sharing details regarding trade secrets, IP, competitive advantages etc.
Only mentioning this because I wish someone had clued me in earlier in my career. I only learned after my friend in opsec called me out for my loose lips.
Only mentioning this because I wish someone had clued me in earlier in my career. I only learned after my friend in opsec called me out for my loose lips.
A good chunk of my time was in SoC eval so if the vendor was being complacent they didn't get the bid. You should always be running multiple solutions so you don't get locked in with a certain vendor(and also a really good reason to keep any tech stack you have highly portable).
Even then though there's ways to approach it that don't disclose. You can set KPIs that you expect to hit and talk through how they plan too approach it from their side. If something is known in the public you can reference it although I generally prefer not to.
Depending on what part of the industry you're in some vendors prefer not to patent and keep approaches internal so discussion of certain aspects can be pretty sensitive.
Even then though there's ways to approach it that don't disclose. You can set KPIs that you expect to hit and talk through how they plan too approach it from their side. If something is known in the public you can reference it although I generally prefer not to.
Depending on what part of the industry you're in some vendors prefer not to patent and keep approaches internal so discussion of certain aspects can be pretty sensitive.
Stratechery (& Dithering) is the only paid newsletter I subscribe to. It’s so worth it. I think that everyone working in tech should subscribe to maintain an objective view of the overall tech landscape. Otherwise, you get sucked into the gravitational well of your employer’s propaganda.
This is especially true at big tech, as Ben covers them often.
This is especially true at big tech, as Ben covers them often.
I am not sure how many people really get sucked into employer’s propaganda. However, it is a great newsletter with good interviews and an energetic and passionate voice on tech.
I think it’s easy to get sucked into it accidentally if the only source of tech news you read is your employer’s internal newsletters.
A bit off topic but every other (public) article from Stratechery reads like a hagiography of Intel. Now he landed an interview with the man himself. Hmm. Pat's time is extraordinarily valuable. Either the author lets his personal bias affect his analysis too much, or there is some PR money at work here.
There's still a lot of interesting analysis but my opinion of the newsletter has soured over time.
There's still a lot of interesting analysis but my opinion of the newsletter has soured over time.
It sounds like you should read more of Ben's articles. He doesn't write about Intel every other article and he has long been critical of them for losing ground to TSMC.
It's telling there's not even mention, even if a jackfruit question, of IME
>Pat's time is extraordinarily valuable.
It is. On the other hand, a not insignificant part of his job is talking to journalists, industry analysts, financial analysts, etc. Doesn't mean just anyone can drop an email and get an interview but, although I haven't spoken with Pat for quite some time, I had 1:1s with him (and did a little work for him) when he was CTO.
It is. On the other hand, a not insignificant part of his job is talking to journalists, industry analysts, financial analysts, etc. Doesn't mean just anyone can drop an email and get an interview but, although I haven't spoken with Pat for quite some time, I had 1:1s with him (and did a little work for him) when he was CTO.
This is OT, but can I just say how amazing it is that the head of a large public tech company is being interviewed by a smart guy with a paid newsletter?
What a world.
Edit: corrected typo.
What a world.
Edit: corrected typo.
A paid newsletter that's read by a large portion of the tech world
> read by a large portion of the tech world
Hmmm. I might take issue with that statement. While the author of Stratechery doesn't seem to have any public numbers, from https://stratechery.com/about/
"Stratechery has subscribers from over 85 different countries, including executives in both technology and industries impacted by technology, venture capitalists and investors, and thousands of other people interested in understanding how and why the Internet is changing everything."
Hmmm. "Thousands"? So let's round up and call it 10k.
From the BLS, approximately 178k Computer Programmers in 2020 in the US: https://www.bls.gov/oes/current/oes151251.htm Just programmers, just in the US.
So 10k is ~5% of programmers in the USA. That's not a 'large' number in my understanding, and that ignores everyone outside of the USA and everyone who is in tech in the USA but not a programmer.
It's hard to find global numbers from a reliable source, but googling around indicates that there are millions of people in the tech sector worldwide.
Hmmm. I might take issue with that statement. While the author of Stratechery doesn't seem to have any public numbers, from https://stratechery.com/about/
"Stratechery has subscribers from over 85 different countries, including executives in both technology and industries impacted by technology, venture capitalists and investors, and thousands of other people interested in understanding how and why the Internet is changing everything."
Hmmm. "Thousands"? So let's round up and call it 10k.
From the BLS, approximately 178k Computer Programmers in 2020 in the US: https://www.bls.gov/oes/current/oes151251.htm Just programmers, just in the US.
So 10k is ~5% of programmers in the USA. That's not a 'large' number in my understanding, and that ignores everyone outside of the USA and everyone who is in tech in the USA but not a programmer.
It's hard to find global numbers from a reliable source, but googling around indicates that there are millions of people in the tech sector worldwide.
Skimmed. I was hoping to read a deeper question about Intel's power consumption. I keep seeing benchmarks showing Intel's massive gains with the 12th gen that avoid talking about power. It's not that hard to match or exceed a competitors benchmark if you double the power budget.
I've read that for the original iPhone Steve Jobs was in talks with Intel to produce a low power x86 chip. Intel said no. The silicon landscape would be very different if that had happened.
I've read that for the original iPhone Steve Jobs was in talks with Intel to produce a low power x86 chip. Intel said no. The silicon landscape would be very different if that had happened.
I calculated once that the cost of buying an intel chip is around double that of a similar performing AMD chip if you factor in the cost of electricity over a few years. Unfortunately for intel, their latest generation is still on very old 10nm technology while AMD is currently on 7nm and is going to 5nm soon. Because of their giant screw-ups with a sales and marketing CEO, Intel has fallen far behind with their own fabs, and power consumption has not improved at all. All they can do for now is sell their latest generation chips with a terrible profit margin in order to compete against AMD.
Not a single word about IME.
Oh that old thing, minor out of band communication never hurt anyone.
What’s that?
Intel management engine. Remote code execution backdoor / feature.
This basically summarizes why Intel is in so much trouble. They can execute well for the next 10 years and they are still hosed - they used to be practically the only supplier (AMD wasn't doing well) of the by far most used architecture in servers (and clients), and sold to 100s of thousands of customers, none of who could push them around. Now there are several architectures and several suppliers and the buyers are bigger and more concentrated than ever. They are just lucky the server market has been growing while the big cloud providers built out. It's not going to be a pretty 10 years to 2032... selling those x86's in 2032 won't be so.. high margin.