Hacker News Reader

> Who knows what kind of crazy performance differences/bugs there are between ARM and x86_64.

A lot of code for demanding applications is often enhanced with SSE/AVX and JIT recompilation techniques. Those are inherently unportable, and I'm not sure how many developers will be willing or able to port that code over to Neon and AArch64, especially for a small 2-4% of the market.

Even if they do, it's quite a cognitive burden to have master and maintain two separate SIMD and recompilation implementations for the same applications.

This will probably further drive high-end gaming away from Macs, on the heels of OpenGL deprecation and the Mac-only Metal API. Combined with Cocoa and Swift, I imagine we'll end up seeing less and less applications that run natively on both Macs and Windows/Linux after the move.

Android is much more than 2-4% of the market, though.

Not in the desktop application space.

> This will probably further drive high-end gaming away from Macs

Agree. I guess people will end up using Stadia/GFN/PS Now, etc.

> Those are inherently unportable

There is sse2neon https://github.com/jratcliff63367/sse2neon. For intrinsics it supports, you only need to add a header. There is also simde https://github.com/nemequ/simde. It is a larger project and may be more complete.

I can't speak for others, but for me it should make no difference as long as they don't nerf the MacOS operating system.

The vast majority of well written C and C++ code will compile and just work on ARM64 as long as it doesn't depend on things that are undefined in the C/C++ spec but X64 lets you get away with. The big bugaboos are unaligned memory access, assembly or X64 intrinsics, and reckless casting. Vector code will need porting (assuming there's not already a NEON version) but that's generally only found in graphics, audio, machine learning, and cryptography applications. Most apps don't have any of that. (Auto-vectorization is irrelevant as the compiler does that.)

Code in higher level or newer languages is generally even less worrisome. Rust, Go, Java, C#, and any dynamic language will just work.

I do expect that these ARM64 chips are going to have lower per-core single-threaded performance but higher parallel performance than X64 due to more cores. That means that some applications may need refactoring or partial redesigns to be more parallel to take full advantage of the chip. But that's something that needs to happen anyway since all architectures are going many-core due to the end of big easy single core performance gains. It's been a long time since huge gains in single threaded performance were a thing.

As long as they don't screw it up by e.g. nerfing the OS I'm looking forward to better battery life and better overall performance due to many cores and lack of X64 instruction decode bottlenecks.

I'm curious about how they'll do it though. I predict instruction translation (X64->ARM64), but also the return of fat binaries. It's also possible that apps distributed through the App Store will be delivered only in your host architecture automatically. I think they were making some noise about that a while ago and that may be prep for this.

I think you are overestimating the change. IMO the OS changes things a lot more than the processor architecture.

Almost nobody (except imgix and a few others) run macos on a prod server, yet many devs run macos. For example: when they run stuff via docker they run it via a VM (whether they know it or not).

Any dev (again, except imgix and a few others) that actually cares about server performance is already not running their benchmarks/perftests/tests on a mac, so that should not make a difference.

> Moreover, I feel like it's going to be a big problem that the architecture you're deploying your code to is different than the one you are developing on.

iOS apps—which run on ARM chips inside iPhones—have all been developed on Intel-based Macs.

macOS has an ARM simulator though. Will they have a “legacy Mac” simulator too?

Where?

If you're speaking of the iOS simulator, that runs on x86, it doesn't emulate an ARM chip.

> I would imagine a lot of tools don't work on ARM

A lot of open source code works well on ARM. But will we start to see some newly-discovered-but-latent arch-specific bugs, compiler bugs, undefined-behavior bugs-but-worked-on-x86_64 bugs? Yes, sure.

The cool thing is that Win/ARM and Linux on arm are still very much the same OS as their x86_64 ports. Presumably macOS is/will be the same way.

ARM gets less love precisely because they're not as popular for developer native workstations. But I wouldn't be surprised if that changes over the next decade.

> Who knows what kind of crazy performance differences/bugs there are between ARM and x86_64.

iOS developers?

Aren’t iPad Pro devices faster than some laptops nowadays?

In certain ways, yes.

Faster is kind of a hard metric to quantify.

Couple of benchmarks show intel clearly winning in the multi-core world but it looks like single core performance is a bit more of a tossup.

https://gadgetversus.com/processor/apple-vs-intel-core-i9-99...

Apple isn't the only company pushing ARM - Microsoft already released Surface Book Pro, AWS has ARM instances, doubt it will take long for Google and Microsoft to add their own ARM flavored CPUs.

Chromebooks have been running ARM forever, so Google already has their platform ARM-ready. In fact, I'd even say ChromeOS is more of a complete desktop suite than any ARM project Microsoft has undertaken as of yet, mostly because of the web-first style of development Google follows.

Wouldn't it be similar to the PowerPC -> Intel transition or is there something that makes this more complicated? That one worked pretty well with the Rosetta emulation layer.

Last time, Apple switched to the "industry standard" architecture with all the benefits that entails; now they're switching away from the (current) "standard".

All iPhones are ARM based chips for a long time already, so it's not something that's completely new to them and by the number of devices it can probably be called a current industry standard too.

That's exactly the difference - iPhones define the industry (co-)standard. Macs do not. They simply don't have the market share.

They don’t need to. It’s all about building the platform that is simple for developers.

They will be able to hit desktop -> mobile in one shot.

my guess is, apple feels that in the near future, "industry standard" → ARM, and thats one of the reasons <insert hockey puck analogy here> they are moving...

That transition was greatly assisted by the huge performance difference between Intel and PowerPC especially for the laptop chips that most users were using.

It took developers a long time to have stuff fully ported, but it wasn't a huge deal - if you switch to a chip that's twice as fast and take a 50% hit on the emulation layer, you haven't lost much.

I'm very curious to see stuff that isn't first- or second-party already-natively-recompiled stuff works. There's a lot of quality-of-life Mac native apps that I like, that aren't backed by a bunch of dev resources.

There is just the opposite precedent for the 68K to PPC transition. My 6100/60 (PPC 601/60) was about the speed of a 68030/25Mhz Mac when running emulated software. It was actually slower than my upgraded 68030/40Mhz Mac when running emulated code. My Mac was less than half the speed of top end 68K Macs.

The PPC Macs couldn’t emulate a 68K floating point unit at all.

the architecture you're deploying your code to is different than the one you are developing on

One thesis of the article is that people will start to deploy on ARM (e.g. Gravitron) so that it will be the same architecture.