[ogre_codes]

This bit about Multi-platform development is most interesting to me.

> Many developers are going to experience multi-platform development for the first time with the M1 Macs. This is one of the key areas where Docker shines. Docker has had support for multi-platform images for a long time, meaning that you can build and run both x86 and ARM images on Desktop today.

If multi platform images work, a lot of the concerns people have about x86 versus ARM should go away.

Of course, once you can do everything on ARM as well as you can on x86. Perhaps changing more of your infrastructure to ARM might make more sense.

[ducktective]

Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"...

And you look into the dockerfile manifest and see that it wants to pull the whole stack of history of computing...Then you figure maybe you don't need that shiny utility in the first place and move on...

It's "64 vs 32-bit" or "Ubuntu vs Arch vs Fedora binary" all over again...

[ogre_codes]

> Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"...

Until we start seeing reasonably priced, performant ARM desktops and laptops, there is little worry of that. Right now outside Apple, performance on ARM isn't good enough for any kind of great developer experience (or any kind of pro experience). Unless that changes significantly, x86 is going to be dominant on non-Macs for some time.

[pjmlp]

On desktops yes, ARM rules on mobile devices and plenty of us code for them, and on Android unless you are doing CRUD like apps, most likely there is some C or C++ code as well.

[totalZero]

Apple is 15% of the personal computer market, if I'm not mistaken. Their intention to abandon x86 isn't a clarion call for the obsolescence of x86.

Personal computers generally go where Windows goes. Heck, that's arguably part of why Apple left PowerPC for Intel in the first place. Apple has tremendous impact on design, form factor, and other visionary steps that the market takes. I do not deny that. Still, in terms of hardware and the development ecosystem, Microsoft simply has a lot more market inertia than does Apple.

This is nothing like 64bit vs 32bit. That was a difficult (MacOS didn't drop 32bit app support until Catalina) but obvious (unless you hate RAM) leap forward. In contrast, Apple Silicon is a leap sideways whose opportunity arose because Intel's flagship process node has had a rough few years. There may be inherent advantages to Apple Silicon as a technology, but nobody should make the unproven assumption that Apple Silicon is universally superior to any and every possible TSMC 5nm x86 chip.

[garciasn]

They are roughly 15% of the US market and about 7% globally.

[jillesvangurp]

X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.

[Wowfunhappy]

Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.

[ogre_codes]

This whole territory is pretty much unknown right now. Whether we can have reasonably performant x86 containers is up in the air.

[musicale]

Yes, it's definitely "performant" if by "performant" you mean "exactly matching the well-established performance of qemu emulation" which means: slower than Rosetta2 with higher CPU/memory/power usage but still functionally correct for the most part.

If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

[skissane]

> If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

I wonder if this would motivate someone to build an x64-to-ARM translation layer for Linux which is closer to Rosetta2 than qemu-user-static in performance?

One of the secrets of Rosetta2's performance is Apple Silicon processor extension enabling ARM code to use the x86 memory model. There is no reason in principle why some x64-to-ARM translator running on Linux on Apple Silicon could not exploit the same processor extension.

Another secret is that it predominantly does AOT translation, and only uses interpretation/JIT for x64 code generated dynamically (such as by an x64 JIT). There is no reason in principle why something on Linux couldn't do the same thing.

Perfect world scenario, Apple would open source Rosetta2 and it would be ported to Linux. Apple probably won't do that because they've invested a lot of money into it and it gives them a competitive advantage over other ARM-based platforms (such as Microsoft Surface Pro X). (I do hope I'm wrong about this though.)

[ant6n]

I’d say the reason qemu is slow isn’t aot vs jit, but that qemu is very generic allowing translation between all sorts of different architectures. It uses an intermediate representation where you lose those possible 1-to-1 mappings between x86 und arm.

I was fiddling for a while on x86 emu for arm, it’s definitely possible to be faster than qemu, but it’s a very big project and unclear whether somebody will just do it in their free time.

[coldtea]

>but still functionally correct for the most part.

Why, would any part be fuctionally incorrect under qemu?

I mean, aside for web and app development, not for writing hardware drivers...

[Wowfunhappy]

I'd expect it to be exactly as performant as qemu's x86 emulation always is. The M1 is new, but qemu is not.

[fomine3]

So it means plain old binary translation without hardware assist. I wonder that whether QEMU's binary translation is not optimized well nowadays because no one uses it for production (we use with VT-x/EPT or AMD equivalent).

[ogre_codes]

I think QEMU is hardware emulation, not translation.

[ant6n]

I have been running x86 containers inside a chromebook for years. Never had a an issue, it’s just a bit slow.

[YetAnotherNick]

> If multi platform images work, a lot of the concerns people have about x86 versus ARM should go away.

Not really. Just because you have ARM and AMD debian, you wouldn't have same behaviour in both. You wouldn't have same list of packages that can be installed.

[acdha]

You'll have extremely close to the same behaviour in both since Debian ships exactly the same versions. It's always possible that there's a compiler bug which only affects one platform but that's relatively uncommon. At one point I was supporting Debian on x86, x86_64, MIPS, and PowerPC. The major portability concern was drivers, which is irrelevant for Docker, and sometimes you'd find performance issues with e.g. OpenSSL having a hand-tuned x86 ASM implementation but relying on the C compiler for another platform but it was rather uncommon.

I am skeptical that anyone will notice a problem unless their workflow is to build a container on their laptop and push it straight to production without testing.

[ogre_codes]

That is fundamentally what I mean when I say "If they work". If the two platforms behave differently, then multi-platform images are pointless.

If 1 in 20 multi-platform images has some kind of oddball cross platform behavior, developers won't be able to rely on them at all. I think we can get far better than that, but we'll see.

[MangoCoffee]

>Of course, once you can do everything on ARM as well as you can on x86.

i have high hope for AMD/TSMC to push x86. Intel seem to be...stuck for now.

[cogman10]

I mean, if the apple approach really works well then I could see AMD or even Intel following suit in the future.

If the industry starts to shift and push towards ARM due to cost, AMD and Intel would be fools to just leave that on the table.

[ogre_codes]

Intel's fat margins are largely based on their duopoly on x86. With ARM, it's far more competitive and margins are far lower. With Nvidia owning ARM, it seems likely we'll see more ARM CPUs from them. Samsung, Qualcomm, and Mediatech also have ARM CPUs all the way down to a few dollars per CPU. Intel isn't going to be able to come in and charge $50-500+ unit the way they do with their x86 chips.

Unless Intel can reboot Moore's Law on Intel, they are going to get hit hard over the next few years. Even if Intel makes the move to ARM, their profitability will take a huge hit from the ARM migration.

[cogman10]

I don't disagree. In fact, I'm assuming that's a major reason they've not done this sooner.

Intel tried to setup a different more efficient architecture with IA64, but they failed there.

That being said, with major players like Amazon and Google tinkering with ARM in the cloud and Apple getting ARM into the hands of a lot of developers, we could be on the eve of seeing ARM make a big entrance into the server realm.

IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development.

[jacques_chester]

> Intel tried to setup a different more efficient architecture with IA64, but they failed there.

A big part of the IA64 strategy was to thoroughly mine the area with patents. They were held in a company jointly owned with HP. In theory it would be impossible for anyone else to reimplement IA64 and "impossible" for IA64 to be licensed to another manufacturer.

[pjmlp]

That reason doesn't make any sense to me.

I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes.

Then I moved into managed languages, where the actual CPU and even underlying OS, only matter to low level coding, again not using the same local OS/CPU combo as the server.

Finally, cross compilation for ARM exists since years.

ARM hasn't taken off, because most of time it doesn't matter enough to displace the existing stacks.

[cogman10]

> I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes.

Things change. Why is x86 the primary server platform? It isn't a great micro architecture. The fact that ARM and others (Like power pc) have been eating their lunch in terms of price, performance, and power consumption is proof enough of that.

So how do you explain the rise of x86 and the fall of pretty much every other platform on servers?

To me, it's simple. x86 got fast enough on consumer hardware to be able to run the same software that would run on servers. Developers like to test their software locally. Emulators for anything to x86 have been terribly slow.

That's why since about the late 90's pretty much everyone has been running x86 servers.

That you can cross compile isn't really the issue. Even running managed languages isn't the issue. The issue is that there are always differences that are hard to compare when switching platforms if the one you are developing on isn't the same as the one you are targeting.

That's like 90% the reason why most consoles have switched over to x86.

Mobile devices would have gone to x86 were it not for the fact that licensing costs were too high and the performance/watt ratio too low.

[klelatti]

Agreed that lack of desktop Arm wasn't the biggest issue. Arm didn't take off because:

- Intel had process leadership and x86 was 'good enough' - Process leadership was in turn supported by the volumes / margins that Intel had on their consumer PC business.

But now Intel has lost process leadership partly due to smartphone volumes supporting huge investment at TSMC / Samsung and the hyperscalers have an incentive to differentiate their offerings (e.g. Amazon Graviton).

[ogre_codes]

I agree.

> IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development.

Also suspect this is largely true. Most developers have local environments and until Apple, having a local environment with ARM has been awkward. Docker multi-platform images is supposed to mitigate this, but they are still fairly new and I suspect many developers don't trust them yet.

It would be interesting to see Apple launch am M series server. After looking at the M1 Mac mini logic board, it seems like a blade server with stacks of Mac mini boards would be fairly easy to engineer. Apple would just need to build the chassis.

(Not holding my breath waiting for this)