"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)"
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).
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!
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.
This was a good argument a couple of decades ago. Now? Keep in mind that most devices in this planet are ARM-based, ever since we started talking about 'smartphones'. They have been running these interpreters for a long time now. Most applications and libraries of any importance have been ported.
> 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.
I thought that's what staging environments were for? Plus scale tests? A laptop provides a pretty poor proxy for a server environment behavior. For starters, they are not really the same spec, are they? Are you running a Xeon-based laptop?
Or, for example, there's one library I use that includes some inline assembly language routines. Which target SSE, not SVE. So, if we're targeting different ISAs, then my dev box isn't even executing the same code as what would be running in production.
That seems crazy to me. What bizarre excuse does your organization have for that policy?
To me, part of the point of a staging environment is to provide something as close as practical to prod in which to test, reproduce, evaluate, and investigate issues, be they performance, correctness, or what have you.
Even if it were allowed, it would still be awkward. I want to, as much as is practicable, find problems as early as possible, and not wait for them to get all the way to staging. I'm not really interested in making myself less able to do my job effectively just because I can.
Nowadays a browser takes that role.
Having a workstation with the same CPU is definitly not an issue as Linus makes it to be.
Java less so, but the behavior and performance characteristics are definitely different.
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.
I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.
I develop and test against docker containers that run on a specific image + arch + base OS.
Even though my environment is supported on ARM, I am still not keen on using ARM servers even if I think it will work. There's just too much risk involved and I don't have the time to set it up and test it thoroughly.
With Python, some of the really useful libraries are written in C so you really need consistency between your environments if you don't want gotchas in your deployment pipelines.
Even more people use macbooks to develop for the browser, or to develop using platform-independent languages: Python, Ruby, Node, maybe even golang.
Quite a few people then package their backend code in a container and test it in a Linux VM which "Docker for Mac" helpfully provides.
But indeed the fact that Macs used to run on Intel, so the libraries you used in development were mostly that same versions of the same code as in production, must have been helping.
People only develop on MacOS because of how similar it is to Unix, not in spite of it. Go ahead, look at how many developers were using MacOS before OSX. I'll wait. The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
> So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
Let's clear this up: there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software. Unless you're working as a web developer (in which case, may god have mercy on your soul), you're probably going to end up using an x86 machine. Hell, my best friend is a die-hard Apple fan, and even he has admit that he can't really upgrade his Xeon iMac unless Apple offers him an upgrade within the x86 ecosystem.
There were plenty of other problems with pre-OSX MacOS.
> The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
The differences between x86 OSX and x86 Linux are bigger than the differences between x86 Linux and ARM Linux, in my experience. So these machines are also "close enough" to ARM servers.
> there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software.
Most developers have a local development environment and a separate production environment. Developers place some value on having them be similar, but they're also happy to introduce differences between local and prod for the sake of other tradeoffs.
Why can't he upgrade? (Genuine question)
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.
It is, but it introduces enough differences that you're not "at home"; indeed I'd say OSX-to-Linux is a bigger difference for development than x86-to-ARM.
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.
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.
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.
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.
I think the lack of availability certainly didn't help, but the architecture itself was probably the biggest downfall of the IA-64 platform. When it was introduced, the hardware was certainly advanced, but relied too much on software to get proper performance out of the chips. The product was doomed from the start.
Ampere will likely have entirely different problems bringing their architecture into the market, but I don't think Itanium ever stood a chance even if they'd sent out free chips to as many influential people and companies as possible.
The architecture was probably a fatal mistake on its own (even if Intel had disbanded its x86 line, the “older” RISC processors outperformed, often substantially) but ensuring that almost nobody saw anything close to what performance it could deliver definitely made it fatal. If Intel hadn’t been greedy trying to charge for compilers, the gap wouldn’t have been nearly as bad.
This must have been a huge part. Maybe ICC could squeeze more MIPS per dollar out of Itanium than x86, but if GCC can't, people are going to not buy Itanium rather than buy ICC.
I think that's the kind of issue they're talking about. If it had been easier for nerds in bedrooms to run Itanium, we'd've seen much better support for it in GCC etc. much sooner.
Back when I supported computational scientists, the total cost of the servers + compilers was so steep that even if everything had worked as well as the Itanium salespeople promised it would have needed to be many times faster to be worth the hassle of changing toolchains, especially since you had to pay up front for the hope that with a fair amount of work you'd at least hit the point of breaking even.
If Itanic had won, we'd still be basically where we are today from a hardware perspective, but with even less competition.
Basically there was no way of getting your hands on them. They were interested only in "Serious customers".
If the market isn't established then you may need to get traction with the dreamers and misfits.
Having seen this play out a number of times I don't think targetting that segment and only that segment is a great idea.
From a stack perspective, you can't really go it alone anymore. The total necessary software universe is too large to rebuild on a reasonable timescale, and too expensive to rebuild by oneself.
IBM is about the smallest scale that can do this -- and even they're leveraging decades of effort.
I'm not affiliated with Avantek in any way. I just did a bunch of research looking to build/buy a desktop, and ARM was a contender, but I ended up building a beefy x86 machine with a Ryzen instead.
Apple made it happen on the client, but Amazon is making it happen on the server. The people who want to run their own DCs or hardware will end up part of the niche left on x86. I don't see Apple doing anything in the server space beyond providing minis like they do now.
(I’m not sure whether that includes servers at large cloud providers, but I don’t think that matters. Unless there’s a huge performance advantage, I don’t see Amazon, Google or Microsoft buying Apple server CPUs)
If they are to be commercialized, I’d expect them to be part of a development stack related to Xcode, or some kind of AWS like services for applications developed for the Apple ecosystem.
Offering generalized compute would invite too much initial cost performance comparison and they couldn’t keep up with demand.
iServer with 64 cores and 256 GiB DDR4 for only $ 699,999.95
You are off by an order of magnitude :)
I never did deliver for the OLPC project, but I tested a lot of things other people were working on. I also finally grokked the free software idea and became and engineer instead of a history teacher.
The $250 or so of prototype hardware has been repaid in testing, bug reporting other things I was able to do then. It sits on a shelf in my office to remind me how I got started, and what it mean to really be a part of a community that takes risks to invest in newcomers.
Pay-As-You-Go is great for trying out new architectures: it's easy to justify spinning a few instances to test whether something can work under ARM. And if it does then convert existing instances to save money. No (hard to get unless you are a large business) dev boards to purchase.
ARM's dominance in the cell phone market means it is ample popular enough, got lots of eyes on it, and increasing amounts of software is picking up dedicated optimisations for it.
I'm not sure what else you're really expecting. The hardware is there. The software is there. Very likely you could switch to ARM without noticing.
[1] Last time I mentioned this to someone involved in POWER architecture, they told me there were going to be cheap POWER based systems coming out to meet the "home hackers" market. I'm not paying particularly close attention, but I haven't seen anything yet?
When I first started developing on AWS, I bought the company a beefy server so we could run virtual machines on it to "test it locally". We bought a dual socket supermicro board and put our choice of Intel Xeons on it. It ended up being north of $2000 (ten+ years ago). At the time AWS c1.xlarge were $0.80 per hour. Paying per hour just felt wrong. And then, within a few months, we had a working system, and we were running 250 c1.xlarge for hours on end, and charging 50x for the end result. The $2000 machine sat idle and was a total waste of money. We developed on our local machines (a Mac), and deployed to test machines on AWS.
Now I pay some hosting company $x per month to host my eldest's minecraft server. I don't want to manage that shit! I have money but not time, and I use my time effectively. That means I don't waste my time buying and configuring servers.
"Hyperscale cloud" is just buzzword for "huge data center somewhere else" so there's not much of a difference except packaging and power (machines for hyperscale data centers often take direct DC power, not AC into one PSU per machine.)
It's available but as you said, not at any reasonable price. The motherboard alone seems to be $5,000.
Once Raspberry Pi CM4 support is added, I assume that you would be able to work on drivers for PCIe devices as well. Besides, non-server vendors like NXP have released official boards with ARM ServerReady support.
The problem with this stance is that they can also keep using the non elitist platform, considering the elitist platform is inferior for many use cases.
No sparks...
I've been a CTO for a decade+ and did try to get one the last time they made a splash.
My message for people trying to make "ARM Server" CPUs a thing is that you have a real chicken or egg problem to solve, getting these things into the hands of people doing Linux development on x86-64 right now. Without a robust ecosystem of all the Taiwan-based motherboard manufacturers behind you, it's never going to get more than a few percent market share.