7 ms·

I remember and interesting speech by Linus Torvalds about success of x86 and why is hard for AMD to break into servers that I think can be relevanto for Ampere

by fbn79 5y ago

I remember and interesting speech by Linus Torvalds about success of x86 and why is hard for AMD to break into servers that I think can be relevanto for Ampere too: "I can pretty much guarantee that as long as everybody does cross-development, the platform won’t be all that stable. Or successful. Some people think that “the cloud” means that the instruction set doesn’t matter. Develop at home, deploy in the cloud. That’s bullshit. If you develop on x86, then you’re going to want to deploy on x86, because you’ll be able to run what you test “at home” (and by “at home” I don’t mean literally in your home, but in your work environment). Which means that you’ll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better… Which in turn means that cloud providers will end up making more money from their x86 side, which means that they’ll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff). Guys, do you really not understand why x86 took over the server market? It wasn’t just all price. It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over. (All emphasis original)"

TheMagicHorsey 5y ago
I'm not sure I agree. Many customers are working at a level of abstraction where this objection is not relevant. For example, if I'm building on Firebase with Cloud Functions I'm so far abstracted from the underlying hardware that these architecture specific issues are less important. Similarly, if I'm working in Django/Python on AWS RDS, using an ARM server for my EC2 instance might be an issue ... but moving my RDS Postgres instance onto ARM might not make a difference.
- cmrdporcupine 5y ago
  It's that way, and you're 100% right, until you hit the corner case performance bug that you can't track down and you spend hours trying to track down why some performance counter is incrementing monotonically on one platform but not on the other. Or why some highly threaded code has great throughput on your development workstation but falls down in production and it probably has something to do with differences in lock behaviour, etc.
  - vlovich123 5y ago
    That’s already true today. At work I have a 12 core laptop with 32gb of RAM. In the cloud is significantly more on all fronts. We encounter all the challenges you mention and still make it work (and yes, it’s hard). That being said, I doubt anyone writing in a managed language or hitting the database will actually care. Databases that have defects on a certain architecture will have resources poured into finding and fixing the issue (although it’s entirely possible there will be cloud lockin for those fixes if they aren’t contributed back)
  - MonaroVXR 5y ago
    This reminds me off that story on hackernews about getting that laptop in the datacenter, because they couldn't figure out why it was slower on the server.
- MaxBarraclough 5y ago
  > moving my RDS Postgres instance onto ARM might not make a difference I have no specific knowledge here but I imagine the x86-64 builds are far better tested, regarding correctness. As cmrdporcupine points out, the performance of the x86-64 builds will also have been better studied. Whether it's an issue in practice, I don't know, but if you're looking to minimize risk, there are good reasons to stick with x86-64.
madeofpalk 5y ago
Most people are essentially developing fancy/overcomplicated wordpress themes. They're at an abstraction where architecture just isn't exposed to them directly, or as much. I can certainly imagine a 'serverless' platform like Lambda or something where running on ARM is just an implementation detail (if it's not already).
- salicideblock 5y ago
  That is true, but it is also true that the WordPress and PHP running on that ARM lambda will not be as stable as the x86 lambda if the vast majority of their developers only run x86 at home.
  - madeofpalk 5y ago
    ("overcomplicated wordpress themes" was just a dig at how a lot of business is just landing pages or essentially blogs)
  - pjmlp 5y ago
    Their developers can ssh/webshell into a cloud instance, just like we used to do with telnet/X-Windows 20 years ago.
kingsuper20 5y ago
>It wasn’t just all price. It was literally this “develop at home” issue. Whether you're right or not, I think I agree with the idea. It also seems to me that, in general, working with a different CPU architecture and instruction set implies that the new & improved stuff has to be significantly better to be worth the cost and risk. At this point, is one really that much better than another? Are large improvements happening at the margin? Another camel that'll poke it's head in the tent, in large/expensive embedded (which I realize that the parts in the article aren't aimed at) is whether a CPU and it's battlegroup of other stuff will be supported right off the bat by software infrastructure and later on by actually being available in the long run. You have to wonder how out on a limb anyone who used a Motorola 88k felt.
Gravityloss 5y ago
If you run things on the JVM or some other VM, then you're relying on that having good support for the architecture.
- pjmlp 5y ago
  What would have been of Java without those Solaris SPARC desktops for everyone to try it out.
lmm 5y ago
If that were actually an important factor then no-one would do development on OSX, because servers don't run OSX, and the debugging, tools etc. are all a bit different on server *nix from what they are on OSX. And yet we see many developers who'd rather use a Macbook. So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
- ip26 5y ago
  Didn't Macbook-as-developer-machine only really take off after the switch to Intel?
  - Edman274 5y ago
    That happened in 2006, and I would argue that the effect of them moving from PowerPC to Intel was dwarfed by the effect of people wanting to be able to do things like iPhone app development.
  - FractalParadigm 5y ago
    I think it was a bit of that, mixed with the iPhone launch and subsequent release of the App Store and third-party apps. Limiting app development and distribution exclusively to Macs through Xcode probably forced a lot of people into using them for the first time. Mac OS X also received UNIX certification around this time IIRC, I wouldn't be surprised if that compatibility pushed some more people tired of fiddling with their OS towards the "it just works" Mac.
  - smoldesu 5y ago
    Macbook-as-developer-machine started getting popular around the release of the iPhone. Apple took the opportunity to lock down their ecosystem and allow you to exclusively build and sign applications on their own platform, basically locking out anyone who isn't a Mac owner.
    - perl4ever 5y ago
      I'm not understanding what you're contrasting when you say they locked out people who didn't own Macs. From 1984 to the iPhone, I believe it was the norm to develop Mac applications on Macs, except for a brief period when the very first models were starved for memory.
twic 5y ago
Linus knows what he knows, but he has some significant blindspots. Here, it's the existence of languages other than C. I think this argument basically doesn't apply to any interpreted or JITted language. I wouldn't be at all worried about deploying my Ruby, Python, or Java app on ARM, having worked with x86 locally. That is, as long as the Ruby, Python, and Java development teams themselves have been able to test on ARM hardware themselves!
- jayd16 5y ago
  That all depends on how far you trust "write once, deploy anywhere." It doesn't have a flawless track record. I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.
- freedomben 5y ago
  Ruby and Python both have significant parts of their implementation and libraries in C, so it's still a significant problem there. Java less so, but the behavior and performance characteristics are definitely different.
  - tachyonbeam 5y ago
    Definitely. A huge chunk of Python and Ruby packages are written as "C extensions", and if those C extensions are going to get compiled on some platform the developers haven't tested them on, it will make for fun surprise bugs. I know Java has C extensions for some things too. I'm curious how much code is actually "pure Java", but I've actually rarely seen Java used at any of the places I worked at.
- mumblemumble 5y ago
  Kindasorta? Even higher level languages still rest atop the native code. For starters, someone's got to maintain the port of the interpreter or VM. It's going to get a lot more attention if developers are using it as their daily driver. And then there are all the other native and system packages that you depend on. For example, I do a lot of work in Python, and I would be very hesitant to have anything but an Intel CPU in my workstation. Because that's what our servers run, and I know that a lot of packages I use include native code that has been carefully tuned for Intel CPUs. If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production. That said, I'd be willing to at least try it. On the other hand, if work started talking about switching to ARM servers in production, I'd instantly be clamoring for a (non-M1) ARM workstation to develop on, because I need to know that I'm not going to get into trouble with packages that get a lot of love in the x86 versions of the native libraries but not so much on ARM.
smoldesu 5y ago
Yep. Wanna know why my M1 Macbook Air never gets any usage? Because all my servers are x86.
- gonzo 5y ago
  if you're not using it,... want to sell it cheap? ;-)
ksec 5y ago
He has a point, although that is not all there is. Most web stuff dont deploy on x86, they deploy on VM or more specifically JVM. Which is someone else's problem. Amazon and Oracle are both spending resource making sure it works flawlessly. I mean seriously, most doing Web Development dont even want to touch the VM. You may want to ask Amazon, who is trying to get as many Graviton 2 produce as possible from TSMC because the demand for them are outstripping supply. And all of that was before Apple even announced their switch to ARM on Mac. For some workload it is half the cost on R6g than x86 instances. And for some like Twitter, they will invest into making sure it works with ARM. Those works get filter down the pipe. Medium-Large size companies see ecosystem matures and clear cost benefits they will move.

by fbn79 5y ago

TheMagicHorsey 5y ago

I'm not sure I agree. Many customers are working at a level of abstraction where this objection is not relevant. For example, if I'm building on Firebase with Cloud Functions I'm so far abstracted from the underlying hardware that these architecture specific issues are less important. Similarly, if I'm working in Django/Python on AWS RDS, using an ARM server for my EC2 instance might be an issue ... but moving my RDS Postgres instance onto ARM might not make a difference.

cmrdporcupine 5y ago
It's that way, and you're 100% right, until you hit the corner case performance bug that you can't track down and you spend hours trying to track down why some performance counter is incrementing monotonically on one platform but not on the other. Or why some highly threaded code has great throughput on your development workstation but falls down in production and it probably has something to do with differences in lock behaviour, etc.
- vlovich123 5y ago
  That’s already true today. At work I have a 12 core laptop with 32gb of RAM. In the cloud is significantly more on all fronts. We encounter all the challenges you mention and still make it work (and yes, it’s hard). That being said, I doubt anyone writing in a managed language or hitting the database will actually care. Databases that have defects on a certain architecture will have resources poured into finding and fixing the issue (although it’s entirely possible there will be cloud lockin for those fixes if they aren’t contributed back)
- MonaroVXR 5y ago
  This reminds me off that story on hackernews about getting that laptop in the datacenter, because they couldn't figure out why it was slower on the server.
MaxBarraclough 5y ago
> moving my RDS Postgres instance onto ARM might not make a difference I have no specific knowledge here but I imagine the x86-64 builds are far better tested, regarding correctness. As cmrdporcupine points out, the performance of the x86-64 builds will also have been better studied. Whether it's an issue in practice, I don't know, but if you're looking to minimize risk, there are good reasons to stick with x86-64.

madeofpalk 5y ago

Most people are essentially developing fancy/overcomplicated wordpress themes. They're at an abstraction where architecture just isn't exposed to them directly, or as much. I can certainly imagine a 'serverless' platform like Lambda or something where running on ARM is just an implementation detail (if it's not already).

salicideblock 5y ago
That is true, but it is also true that the WordPress and PHP running on that ARM lambda will not be as stable as the x86 lambda if the vast majority of their developers only run x86 at home.
- madeofpalk 5y ago
  ("overcomplicated wordpress themes" was just a dig at how a lot of business is just landing pages or essentially blogs)
- pjmlp 5y ago
  Their developers can ssh/webshell into a cloud instance, just like we used to do with telnet/X-Windows 20 years ago.

kingsuper20 5y ago

>It wasn’t just all price. It was literally this “develop at home” issue. Whether you're right or not, I think I agree with the idea. It also seems to me that, in general, working with a different CPU architecture and instruction set implies that the new & improved stuff has to be significantly better to be worth the cost and risk. At this point, is one really that much better than another? Are large improvements happening at the margin? Another camel that'll poke it's head in the tent, in large/expensive embedded (which I realize that the parts in the article aren't aimed at) is whether a CPU and it's battlegroup of other stuff will be supported right off the bat by software infrastructure and later on by actually being available in the long run. You have to wonder how out on a limb anyone who used a Motorola 88k felt.

Gravityloss 5y ago

If you run things on the JVM or some other VM, then you're relying on that having good support for the architecture.

pjmlp 5y ago
What would have been of Java without those Solaris SPARC desktops for everyone to try it out.

lmm 5y ago

If that were actually an important factor then no-one would do development on OSX, because servers don't run OSX, and the debugging, tools etc. are all a bit different on server *nix from what they are on OSX. And yet we see many developers who'd rather use a Macbook. So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.

ip26 5y ago
Didn't Macbook-as-developer-machine only really take off after the switch to Intel?
- Edman274 5y ago
  That happened in 2006, and I would argue that the effect of them moving from PowerPC to Intel was dwarfed by the effect of people wanting to be able to do things like iPhone app development.
- FractalParadigm 5y ago
  I think it was a bit of that, mixed with the iPhone launch and subsequent release of the App Store and third-party apps. Limiting app development and distribution exclusively to Macs through Xcode probably forced a lot of people into using them for the first time. Mac OS X also received UNIX certification around this time IIRC, I wouldn't be surprised if that compatibility pushed some more people tired of fiddling with their OS towards the "it just works" Mac.
- smoldesu 5y ago
  Macbook-as-developer-machine started getting popular around the release of the iPhone. Apple took the opportunity to lock down their ecosystem and allow you to exclusively build and sign applications on their own platform, basically locking out anyone who isn't a Mac owner.
  - perl4ever 5y ago
    I'm not understanding what you're contrasting when you say they locked out people who didn't own Macs. From 1984 to the iPhone, I believe it was the norm to develop Mac applications on Macs, except for a brief period when the very first models were starved for memory.

twic 5y ago

Linus knows what he knows, but he has some significant blindspots. Here, it's the existence of languages other than C. I think this argument basically doesn't apply to any interpreted or JITted language. I wouldn't be at all worried about deploying my Ruby, Python, or Java app on ARM, having worked with x86 locally. That is, as long as the Ruby, Python, and Java development teams themselves have been able to test on ARM hardware themselves!

jayd16 5y ago
That all depends on how far you trust "write once, deploy anywhere." It doesn't have a flawless track record. I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.
freedomben 5y ago
Ruby and Python both have significant parts of their implementation and libraries in C, so it's still a significant problem there. Java less so, but the behavior and performance characteristics are definitely different.
- tachyonbeam 5y ago
  Definitely. A huge chunk of Python and Ruby packages are written as "C extensions", and if those C extensions are going to get compiled on some platform the developers haven't tested them on, it will make for fun surprise bugs. I know Java has C extensions for some things too. I'm curious how much code is actually "pure Java", but I've actually rarely seen Java used at any of the places I worked at.
mumblemumble 5y ago
Kindasorta? Even higher level languages still rest atop the native code. For starters, someone's got to maintain the port of the interpreter or VM. It's going to get a lot more attention if developers are using it as their daily driver. And then there are all the other native and system packages that you depend on. For example, I do a lot of work in Python, and I would be very hesitant to have anything but an Intel CPU in my workstation. Because that's what our servers run, and I know that a lot of packages I use include native code that has been carefully tuned for Intel CPUs. If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production. That said, I'd be willing to at least try it. On the other hand, if work started talking about switching to ARM servers in production, I'd instantly be clamoring for a (non-M1) ARM workstation to develop on, because I need to know that I'm not going to get into trouble with packages that get a lot of love in the x86 versions of the native libraries but not so much on ARM.

smoldesu 5y ago

Yep. Wanna know why my M1 Macbook Air never gets any usage? Because all my servers are x86.

gonzo 5y ago
if you're not using it,... want to sell it cheap? ;-)

ksec 5y ago

He has a point, although that is not all there is. Most web stuff dont deploy on x86, they deploy on VM or more specifically JVM. Which is someone else's problem. Amazon and Oracle are both spending resource making sure it works flawlessly. I mean seriously, most doing Web Development dont even want to touch the VM. You may want to ask Amazon, who is trying to get as many Graviton 2 produce as possible from TSMC because the demand for them are outstripping supply. And all of that was before Apple even announced their switch to ARM on Mac. For some workload it is half the cost on R6g than x86 instances. And for some like Twitter, they will invest into making sure it works with ARM. Those works get filter down the pipe. Medium-Large size companies see ecosystem matures and clear cost benefits they will move.