8 ms·

In a certain way, this move is horizontally integrated. Intel vertically integrated its chip design and fab. This moves design and fab apart. One of the reas

by mdasen 7y ago

In a certain way, this move is horizontally integrated. Intel vertically integrated its chip design and fab. This moves design and fab apart. One of the reasons that Intel is falling so far behind is that they can't keep up with TSMC (and maybe others as well) on the fab side. Intel's vertical integration worked well for them for so many years. However, the crack has been around long enough for others to start muscling in. AWS can push Graviton because Intel has been stuck at 14nm for so long (yes, they have some 10nm parts now, but it's been limited). Apple can push a move to ARM desktop/laptops because Intel has stagnated on the fab side. I wouldn't say this is a reversal of that revolution as much as a demonstration of the power and fragility of vertical integration. Intel's vertical integration of design and fab gave them a lot of power. Money from chip sales drove fab improvements for a long time and kept them well ahead of competitors. However, enough stumbling left them in a fragile place. I think part of it is that ARM also has reference implementations that people can use as starting blocks. I don't know a lot about chip design myself, but it seems like it would be a lot easier to start off with a working processor and improve it than starting from scratch. I think we're just seeing a dominant player that no one really likes stumble for long enough combined with people willing to target ARM. Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me and if AWS can offer me ARM servers at a discount, I might as well take advantage of that. Intel pressed its fab advantage and the importance of the x86 instruction set against everyone. Now Intel has a worse fab and their instruction set isn't as important anymore. They've basically lost their two competitive advantages. I'm not arguing that Intel is dying, but they're certainly in a weaker position than they used to be.

koolba 7y ago
NodeJS is in that category as well. If you avoid native modules it’s easy to cross deploy on ARM. The workload seem to translate well to the process model of scaling out as well.
- TheSoftwareGuy 7y ago
  Really though, unless you're writing x86 assembly, any language should be just fine on ARM. The only potential holdp is is you rely on precompiled binaries at some point. Otherwise it should just be a matter of hitting the compile button again.
  - sharpneli 7y ago
    In C/C++ land the kind of ”Just try and see if it works” kind of development is super common in proprietary software. Leading to issues such as: Using volatile for threadsafe stuff. Arm has weaker memory model than X86 so it requires barriers. C++ standard threading lib handles this for you but not everyone uses it. Memory alignment. Arm tends to be more critical of that. While it’s impossible for well formed C++ program to mess it up it’s quite common for people just go ”Hey it’s just a number” and go full yolo with it. Because hey, it works on their machine.
    - pjscott 7y ago
      Apple's recent 64-bit ARM processors now support unaligned memory access, so there's one porting problem out of the way: https://developer.arm.com/docs/den0024/latest/an-introduction-to-the-armv8-instruction-sets/the-armv8-instruction-sets/addressing https://developer.arm.com/docs/den0024/latest/an-introductio...
- The_Colonel 7y ago
  It's difficult to avoid native modules though. Many basic things like SQLite or image manipulation are binary blobs.
  - yellowapple 7y ago
    In SQLite's case (and probably in the case of most reasonably popular image manipulation libraries), those binary blobs very likely already exist or can be readily recreated. ARM is not some newfangled obscure architecture; SQLite's been used to great success on far more exotic platforms than that (including, I'd imagine, on devices running iOS).
- api 7y ago
  I seldom see issues porting C and C++ to ARM unless people do weird things with casts that are undefined in the language spec but that work on X86 or use X86-specific vector intrinsics. Most well-written C and C++ compiles out of the box to ARM and just works.
Retric 7y ago
I think a larger piece is intel was able to jump from desktops to laptops but not cellphones. This meant TSMC simply had more economy of scale to push fab’s further.
- dangus 7y ago
  I never understood why Intel gave up on smartphone chips. I remember thinking at the time how that would bite them in the next 10 years. I had an ASUS ZenFone 2 powered by Intel. It was fantastic! I didn’t notice any problems or major slowness compared to a Qualcomm chip. To me it seemed like they had a competent product they could iterate on. And they just canceled the program, how short-sighted! I mean, maybe I’m wrong here and there isn’t really money in that business.
  - wolfgke 7y ago
    Intel was actually subsidizing smartphone vendors who wanted to use Intel chips. Unluckily hardly any smartphone vendor wanted to react to this offer (except some small experiments like the mentioned ASUS ZenFone 2).
  - stonemetal12 7y ago
    I get thinking phones were to small of a market or margins were too thin back then. But you would think when the smart phone market got bigger and prices went up someone would have re-evaluated that decision.
  - sgerenser 7y ago
    People also forget that Intel had a pretty decent line of ARM CPUs right before the time the iPhone was released (XScale). And they gave up on those too, just in time for the market for smartphone CPUs to explode.
    - pavlov 7y ago
      Not only pretty decent — XScale was the best and fastest ARM for PDA-size devices. The only reason Intel killed XScale was that it wasn't x86, it came through an acquisition, and they were afraid to cannibalize their own x86-based mobile plans. Turns out it would have been far better to disrupt yourself rather than let others do it.
notyourday 7y ago
> M. Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me and if AWS can offer me ARM servers at a discount, I might as well take advantage of that. I think that's the fundamental mistake in reasoning: If ARM is cheaper for AWS, then AWS has no reason at all to offer it to its customers at a discount because the customers will not move if no discount if offered. As long as there's no mass market for ARM PCs/servers that work with all the modern software that anyone can rack and sell a-la ServInt/Erols/EV1 circa 1996 there won't be pricing pressure. This has played time and time again in transit pricing.
- mastax 7y ago
  AWS is offering ARM servers at a discount right now.
  - notyourday 7y ago
    One cannot buy another ARM with the same performance and compare it head to head. AWS ARM is instances are mattress market.
dr_zoidberg 7y ago
> One of the reasons that Intel is falling so far behind is that they can't keep up with TSMC (and maybe others as well) on the fab side Actually more that they bit way more than they could chew when they started the original 10nm node, which would've been incredibly powerful if they had managed to pull it right. But they couldn't, and so they stagnated on 14nm and had to improve that node forever and ever. They also stagnated the microarch, because Skylake was amazing beyond other (cutting corners on speculative execution, yes), so all the folowing lakes where just rehashes of Skylake. Those were bad decisions that were tied to Intel not solving the 10nm node (temember tick-tock? Which then became architecture-node-optimztion? And then it was just tick-tock-tock-tock-tock forever and ever), and insisting on a microarch that, as time went by, started to show it's age. Meanwhile AMD was running from behind, but they had clearly identified their shortcommings and how they could effectively tackle thme. Having the option to manufacture with either Global Foundries or TSMC was just another good decision, but not really a game changer until TSMC showed that 7nm was not just marketing fad, but a clearly superior node than 14nm+++ (and a good competitor to 10nm+, which Intel still is ironing). That brings us to 2020, where AMD is about to beat them hard both on mobile (for the first time ever) and yet again on desktop, with "just" a new microarch (Zen 3, coming late 2020). The fact that this new microarch will be manufactured on 7nm+ is just icing on the cake, even if AMD stayed in the 7nm process they'd still have a clear advantge over Zen 2 (of course, their own) and against anything Intel can place in front of them. That brings us to Apple. Apple is choosing to manufacture their own chips for notebooks not because there's no good x86 part, but because they can and want to. This is simply further vertical integration for them. And this way the can couple their A-whatever chips ever more tightly with their software and their needs. Not a bad thing per-se, but it will separate even more the macs from a developer perspective. And despite CS having improved a lot in the field of emulation, cross compilers, and whatever clever trick we can think of to get x86-over-ARM, I think in the end this move will severely affect software that is developed multiplatform (this'd be mac/windows/linux, take two and ignore the other). This is some slight debacle that we've seen with consoles and PC games before. PC, Xbox (can't remember which) and PS3 were three very different platforms back in 2005-ish. And while the PS3 held a monster processors which was indeed a "supercomputer on a chip" (for it's time), it was extremely alien. Games which were developed to be multiplatform had to be developed at a much higher cost, because they could not have an entirely shared code base. Remember Skyrim being optimized by a mod? That was because the PC version was based on the Xbox version, but they had to turn off all compiler optimizations to get it to compile. And that shipped because they had to. Now imagine having Adobe shipping a non-optimized mac-ARM version of their products because they had to turn off a lot of optimizations from their products to get them to compile. Will it be that Adobe suddenly started making bad software, or that Adobe-on-Mac is now slow? Maybe I got a little ranty here. In the end, I guess time will tell if this was a good or a bad move from Apple.
DeathArrow 7y ago
>Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me Me too. But if the apps I need don't come to ARM, I don't care too much about ARM on the desktop/laptop/workstation.
lsorber 7y ago
In what sense has Intel vertically integrated design and fab according to you?
_bxg1 7y ago
> Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me I think you make a key point here. A whole lot of code now runs inside one runtime or another, and even outside of that, cross-architeture toolchains have gotten a lot better partly thanks to LLVM. The instruction set just doesn't matter even to most programmers these days.

by mdasen 7y ago

koolba 7y ago

NodeJS is in that category as well. If you avoid native modules it’s easy to cross deploy on ARM. The workload seem to translate well to the process model of scaling out as well.

TheSoftwareGuy 7y ago
Really though, unless you're writing x86 assembly, any language should be just fine on ARM. The only potential holdp is is you rely on precompiled binaries at some point. Otherwise it should just be a matter of hitting the compile button again.
- sharpneli 7y ago
  In C/C++ land the kind of ”Just try and see if it works” kind of development is super common in proprietary software. Leading to issues such as: Using volatile for threadsafe stuff. Arm has weaker memory model than X86 so it requires barriers. C++ standard threading lib handles this for you but not everyone uses it. Memory alignment. Arm tends to be more critical of that. While it’s impossible for well formed C++ program to mess it up it’s quite common for people just go ”Hey it’s just a number” and go full yolo with it. Because hey, it works on their machine.
  - pjscott 7y ago
    Apple's recent 64-bit ARM processors now support unaligned memory access, so there's one porting problem out of the way: https://developer.arm.com/docs/den0024/latest/an-introduction-to-the-armv8-instruction-sets/the-armv8-instruction-sets/addressing https://developer.arm.com/docs/den0024/latest/an-introductio...
The_Colonel 7y ago
It's difficult to avoid native modules though. Many basic things like SQLite or image manipulation are binary blobs.
- yellowapple 7y ago
  In SQLite's case (and probably in the case of most reasonably popular image manipulation libraries), those binary blobs very likely already exist or can be readily recreated. ARM is not some newfangled obscure architecture; SQLite's been used to great success on far more exotic platforms than that (including, I'd imagine, on devices running iOS).
api 7y ago
I seldom see issues porting C and C++ to ARM unless people do weird things with casts that are undefined in the language spec but that work on X86 or use X86-specific vector intrinsics. Most well-written C and C++ compiles out of the box to ARM and just works.

Retric 7y ago

I think a larger piece is intel was able to jump from desktops to laptops but not cellphones. This meant TSMC simply had more economy of scale to push fab’s further.

dangus 7y ago
I never understood why Intel gave up on smartphone chips. I remember thinking at the time how that would bite them in the next 10 years. I had an ASUS ZenFone 2 powered by Intel. It was fantastic! I didn’t notice any problems or major slowness compared to a Qualcomm chip. To me it seemed like they had a competent product they could iterate on. And they just canceled the program, how short-sighted! I mean, maybe I’m wrong here and there isn’t really money in that business.
- wolfgke 7y ago
  Intel was actually subsidizing smartphone vendors who wanted to use Intel chips. Unluckily hardly any smartphone vendor wanted to react to this offer (except some small experiments like the mentioned ASUS ZenFone 2).
- stonemetal12 7y ago
  I get thinking phones were to small of a market or margins were too thin back then. But you would think when the smart phone market got bigger and prices went up someone would have re-evaluated that decision.
- sgerenser 7y ago
  People also forget that Intel had a pretty decent line of ARM CPUs right before the time the iPhone was released (XScale). And they gave up on those too, just in time for the market for smartphone CPUs to explode.
  - pavlov 7y ago
    Not only pretty decent — XScale was the best and fastest ARM for PDA-size devices. The only reason Intel killed XScale was that it wasn't x86, it came through an acquisition, and they were afraid to cannibalize their own x86-based mobile plans. Turns out it would have been far better to disrupt yourself rather than let others do it.

notyourday 7y ago

> M. Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me and if AWS can offer me ARM servers at a discount, I might as well take advantage of that. I think that's the fundamental mistake in reasoning: If ARM is cheaper for AWS, then AWS has no reason at all to offer it to its customers at a discount because the customers will not move if no discount if offered. As long as there's no mass market for ARM PCs/servers that work with all the modern software that anyone can rack and sell a-la ServInt/Erols/EV1 circa 1996 there won't be pricing pressure. This has played time and time again in transit pricing.

mastax 7y ago
AWS is offering ARM servers at a discount right now.
- notyourday 7y ago
  One cannot buy another ARM with the same performance and compare it head to head. AWS ARM is instances are mattress market.

dr_zoidberg 7y ago

> One of the reasons that Intel is falling so far behind is that they can't keep up with TSMC (and maybe others as well) on the fab side Actually more that they bit way more than they could chew when they started the original 10nm node, which would've been incredibly powerful if they had managed to pull it right. But they couldn't, and so they stagnated on 14nm and had to improve that node forever and ever. They also stagnated the microarch, because Skylake was amazing beyond other (cutting corners on speculative execution, yes), so all the folowing lakes where just rehashes of Skylake. Those were bad decisions that were tied to Intel not solving the 10nm node (temember tick-tock? Which then became architecture-node-optimztion? And then it was just tick-tock-tock-tock-tock forever and ever), and insisting on a microarch that, as time went by, started to show it's age. Meanwhile AMD was running from behind, but they had clearly identified their shortcommings and how they could effectively tackle thme. Having the option to manufacture with either Global Foundries or TSMC was just another good decision, but not really a game changer until TSMC showed that 7nm was not just marketing fad, but a clearly superior node than 14nm+++ (and a good competitor to 10nm+, which Intel still is ironing). That brings us to 2020, where AMD is about to beat them hard both on mobile (for the first time ever) and yet again on desktop, with "just" a new microarch (Zen 3, coming late 2020). The fact that this new microarch will be manufactured on 7nm+ is just icing on the cake, even if AMD stayed in the 7nm process they'd still have a clear advantge over Zen 2 (of course, their own) and against anything Intel can place in front of them. That brings us to Apple. Apple is choosing to manufacture their own chips for notebooks not because there's no good x86 part, but because they can and want to. This is simply further vertical integration for them. And this way the can couple their A-whatever chips ever more tightly with their software and their needs. Not a bad thing per-se, but it will separate even more the macs from a developer perspective. And despite CS having improved a lot in the field of emulation, cross compilers, and whatever clever trick we can think of to get x86-over-ARM, I think in the end this move will severely affect software that is developed multiplatform (this'd be mac/windows/linux, take two and ignore the other). This is some slight debacle that we've seen with consoles and PC games before. PC, Xbox (can't remember which) and PS3 were three very different platforms back in 2005-ish. And while the PS3 held a monster processors which was indeed a "supercomputer on a chip" (for it's time), it was extremely alien. Games which were developed to be multiplatform had to be developed at a much higher cost, because they could not have an entirely shared code base. Remember Skyrim being optimized by a mod? That was because the PC version was based on the Xbox version, but they had to turn off all compiler optimizations to get it to compile. And that shipped because they had to. Now imagine having Adobe shipping a non-optimized mac-ARM version of their products because they had to turn off a lot of optimizations from their products to get them to compile. Will it be that Adobe suddenly started making bad software, or that Adobe-on-Mac is now slow? Maybe I got a little ranty here. In the end, I guess time will tell if this was a good or a bad move from Apple.

DeathArrow 7y ago

>Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me Me too. But if the apps I need don't come to ARM, I don't care too much about ARM on the desktop/laptop/workstation.

lsorber 7y ago

In what sense has Intel vertically integrated design and fab according to you?

_bxg1 7y ago

> Whether I run my Python or C# or Java on ARM or Intel doesn't matter too much to me I think you make a key point here. A whole lot of code now runs inside one runtime or another, and even outside of that, cross-architeture toolchains have gotten a lot better partly thanks to LLVM. The instruction set just doesn't matter even to most programmers these days.