31–40 of 431 posts
Semiconductor manufacturing is just one example where this is happening, electronics is another. Maybe one day Toyota Auto fabs will be making Teslas.
Earlier quoted context omitted.
Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than y…
It's not the memory model I'm thinking of but the cache design, ROB size etc. Obviously this is fairly niche but the friction to making something fast is hugely easier locally.
I partially agree with you though, as the penetration of Arm goes deeper into the programmer ecosystem, any mental roadblocks about deploying to Arm will disappear. It is a mindset issue, not a technical one.
In the 80s and 90s there were lots of alternative architectures and it wasn't a big deal, granted the software stacks were much much smaller and more metal. Now they are huge, but more abstract and farther away from machine issues.
Earlier quoted context omitted.
Professional laptops don’t last that long, and a lot of developers are given MBPs for their work. I personally expect that I’ll get a M1 laptop from my employer within the next 2 years. At that point the pressure to migrate from x86 to ARM will start to increase.
You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. Graviton2 is a Neoverse core from Arm and it's totally separate from M1. Besides, Apple don't let you play with PMCs easily and I'm assuming they won't be publishing any event tables any time soon so unless they get reverse engineered you'll have to do it through xcode.
And keep in mind this is about reducing the incentive to switch to a chip that’s cheaper per compute unit in the cloud. If Graviton 2 was more expensive or just equal in price to x86, I doubt that M1 laptops alone would be enough to incentivize a switch.
Earlier quoted context omitted.
The demise of x86 isn't something that can be fiated. It could come about, but there would need to be a very compelling reason to motivate the transition. Technologies that form basic business and infrastructural bedrock don't go away just because of one iteration -- look at Windows Vista for example. Even if every PC and server chip manufacturer were to eradicate x86 from their product offerings tomorrow, you'd stil…
I was extremely careful not to say that x86 would go away! But it doesn't have to for Intel to feel the ill effects. There just have to be viable alternatives that drive down the price of their x86 offerings.
Intel has already driven its prices downward aggressively [0]. That seems to be part of their strategy to contain AMD while they get their own business firing on all cylinders again, and it's going to be true regardless of whether the majority of the market demands x86 or not. The more that Intel can pressure AMD's gross margin, the more relevant Intel's synergies from being an IDM can become.
[0] https://www.barrons.com/articles/intel-is-starting-a-price-w...
Earlier quoted context omitted.
Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than y…
It's not the memory model I'm thinking of but the cache design, ROB size etc. Obviously this is fairly niche but the friction to making something fast is hugely easier locally.
There is certainly an exception to this for chips with radically different designs and layouts, as well as folks writing very low-level performance sensitive code which can benefit from specific platform optimization ( graphics comes to mind ).
However even in the latter case, I'd imagine the platform specific and fallback platform agnostic code will be within 10-50% performance of each other. Meaning a particularly well designed chip could make the platform agnostic code cheaper on either a raw performance basis or cost/performance basis.
I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to present. My standing theory is that the m1 will accelerate it. Obviously all the wholly managed AWS services (Dynamo, Kinesis, S3, etc.) can change over silently, but the issue is EC2. I have a MBP, as do all of my engineers. Within a few years all of these ma…
Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value.
If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are located in the west, they also have a massive IP portfolio related to everything form IC design to manufacturing.
Feel this piece ducks one of the most important questions - what is the future and value of x86 to Intel? For a long time x86 was one half of the moat but it feels like that moat is close to crumbling. Once that happens the value of the design part of the business will be much, much lower - especially if they have to compete with an on form AMD. Can they innovate their way out of this? Doesn't look entirely promising…
I suppose Microsoft would be influential here. Native Arm64 MS Office, for example.
Feel this piece ducks one of the most important questions - what is the future and value of x86 to Intel? For a long time x86 was one half of the moat but it feels like that moat is close to crumbling. Once that happens the value of the design part of the business will be much, much lower - especially if they have to compete with an on form AMD. Can they innovate their way out of this? Doesn't look entirely promising…
The demise of x86 isn't something that can be fiated. It could come about, but there would need to be a very compelling reason to motivate the transition. Technologies that form basic business and infrastructural bedrock don't go away just because of one iteration -- look at Windows Vista for example. Even if every PC and server chip manufacturer were to eradicate x86 from their product offerings tomorrow, you'd stil…
Those are different things. We have seen a minuscule movement on the first, but we've been running towards the second since the 90's, and looks like we are close now.
I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to present. My standing theory is that the m1 will accelerate it. Obviously all the wholly managed AWS services (Dynamo, Kinesis, S3, etc.) can change over silently, but the issue is EC2. I have a MBP, as do all of my engineers. Within a few years all of these ma…
At that point if it will be trouble for Intel it would be a death sentence for AMD... Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value. If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are l…