5 ms·

How is the developer ecosystem going to fair? I would imagine a lot of tools don't work on ARM (or aren't regular tested on ARM). Moreover, I feel like it's goi

by smabie 6y ago

How is the developer ecosystem going to fair? I would imagine a lot of tools don't work on ARM (or aren't regular tested on ARM). 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. Who knows what kind of crazy performance differences/bugs there are between ARM and x86_64. Also, what about the audio/video/modeling software? I can't imagine that there's any support for ARM at the moment in that space. Also, is the Mac Pro going to switch to ARM? I'm not aware of an ARM chip that can compete with the super highend Xeons in the Pro. Having laptops run ARM and Pros run x86_64 doesn't seem like the best idea (also sounds like a lot of work on Apple's part). Of course, maybe this switch is going to create a high-end ARM space, allowing ARM to make inroads into HEDT and the server market. A lot seems unclear at the moment, but one thing is clear (to me atleast): there's going to be a huge fight over the next 10 years, x86_64 vs ARM. No one can possibly know who will win, but it's exciting to the say the least. I think we've all been a little tired of the x86_64 monoculture since the end of PPC.

wyldfire 6y ago
> 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.
dewey 6y ago
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.
- wmf 6y ago
  Last time, Apple switched to the "industry standard" architecture with all the benefits that entails; now they're switching away from the (current) "standard".
  - dewey 6y ago
    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.
    - kspacewalk2 6y ago
      That's exactly the difference - iPhones define the industry (co-)standard. Macs do not. They simply don't have the market share.
      - nojito 6y ago
        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.
  - andrekandre 6y ago
    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...
- majormajor 6y ago
  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.
  - scarface74 6y ago
    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.
SahAssar 6y ago
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.
cirno 6y ago
> 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.
- saagarjha 6y ago
  Android is much more than 2-4% of the market, though.
  - deleted 6y ago
    [deleted]
  - monocasa 6y ago
    Not in the desktop application space.
- deadmutex 6y ago
  > This will probably further drive high-end gaming away from Macs Agree. I guess people will end up using Stadia/GFN/PS Now, etc.
- attractivechaos 6y ago
  > Those are inherently unportable There is sse2neon https://github.com/jratcliff63367/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 https://github.com/nemequ/simde. It is a larger project and may be more complete.
saagarjha 6y ago
> Who knows what kind of crazy performance differences/bugs there are between ARM and x86_64. iOS developers?
- applecrazy 6y ago
  Aren’t iPad Pro devices faster than some laptops nowadays?
  - saagarjha 6y ago
    In certain ways, yes.
  - jki275 6y ago
    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-9980hk/ https://gadgetversus.com/processor/apple-vs-intel-core-i9-99...
wmf 6y ago
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.
api 6y ago
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.
paulvs 6y ago
> 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.
- wonderlg 6y ago
  macOS has an ARM simulator though. Will they have a “legacy Mac” simulator too?
  - saagarjha 6y ago
    Where?
  - ajuhasz 6y ago
    If you're speaking of the iOS simulator, that runs on x86, it doesn't emulate an ARM chip.
rubber_duck 6y ago
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.
- jeroenhd 6y ago
  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.
deleted 6y ago
[deleted]

by smabie 6y ago

wyldfire 6y ago

> 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.

dewey 6y ago

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.

wmf 6y ago
Last time, Apple switched to the "industry standard" architecture with all the benefits that entails; now they're switching away from the (current) "standard".
- dewey 6y ago
  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.
  - kspacewalk2 6y ago
    That's exactly the difference - iPhones define the industry (co-)standard. Macs do not. They simply don't have the market share.
    - nojito 6y ago
      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.
- andrekandre 6y ago
  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...
majormajor 6y ago
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.
- scarface74 6y ago
  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.

SahAssar 6y ago

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.

cirno 6y ago

> 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.

saagarjha 6y ago
Android is much more than 2-4% of the market, though.
- deleted 6y ago
  [deleted]
- monocasa 6y ago
  Not in the desktop application space.
deadmutex 6y ago
> This will probably further drive high-end gaming away from Macs Agree. I guess people will end up using Stadia/GFN/PS Now, etc.
attractivechaos 6y ago
> Those are inherently unportable There is sse2neon https://github.com/jratcliff63367/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 https://github.com/nemequ/simde. It is a larger project and may be more complete.

saagarjha 6y ago

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

applecrazy 6y ago
Aren’t iPad Pro devices faster than some laptops nowadays?
- saagarjha 6y ago
  In certain ways, yes.
- jki275 6y ago
  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-9980hk/ https://gadgetversus.com/processor/apple-vs-intel-core-i9-99...

wmf 6y ago

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.

api 6y ago

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.

paulvs 6y ago

> 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.

wonderlg 6y ago
macOS has an ARM simulator though. Will they have a “legacy Mac” simulator too?
- saagarjha 6y ago
  Where?
- ajuhasz 6y ago
  If you're speaking of the iOS simulator, that runs on x86, it doesn't emulate an ARM chip.

rubber_duck 6y ago

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.

jeroenhd 6y ago
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.

deleted 6y ago

[deleted]