4 ms·

I know Apple has gone through these transitions before (68K -> PWR -> Intel). But if there is a move to ARM this is the first time they have moved away from a c

by jmount 8y ago

I know Apple has gone through these transitions before (68K -> PWR -> Intel). But if there is a move to ARM this is the first time they have moved away from a currently dominant ecosystem (yes, to another popular one in this case; but the earlier moves were all abandon ship style transitions). I don't see a lot of motivation for pre-compiled open source projects (such as R/CRAN) to maintain two copies of their software (one Apple AMD64 and one Apple ARM64) during the transition. Yet another thing that is going to make Macs less convenient for research and development.

derefr 8y ago
I would expect that Apple would bring back the Rosetta component for such cases (i.e. the same interface to the OS, but now a component doing Intel->ARM dynamic binary translation rather than PWR->Intel dynamic binary translation.) Actually, maybe dymamic binary translation wouldn't be needed all that often. A new Rosetta would likely also be helped out quite a bit by the fact that modern macOS binaries contain embedded copies of their their LLVM intermediate representation; you could transpile that IR (by patching Intel-targeted intrinsics with ARM polyfills) and then run it through the LLVM optimizer again, and then cache the result. That's a fully static binary translation, and the resulting binaries would probably be pretty fast. (You'd still need dynamic binary translation for anything with its own JIT, but maybe there are few enough programs with their own JITs—and all such programs are "big" enough in terms of development resources—that Apple can require these to ship an ARM target. In which case, maybe they don't need to build a new dynamic binary translation component at all!)
- jmount 8y ago
  The translation stuff may be okay for user code (and I know Apple has done it before). But for scientific code it is just too much cost and too many things to break. I know scientists are not Apple's target market, but this just makes getting a Linux laptop a much better proposition.
ttul 8y ago
If the ARM components enable a better power to weight ratio, these laptops will sell very well.
mikhailt 8y ago
> I don't see a lot of motivation for pre-compiled open source projects (such as R/CRAN) to maintain two copies of their software (one Apple AMD64 and one Apple ARM64) during the transition. Yet another thing that is going to make Macs less convenient for research and development. You might want to go look at Apple's history at how they managed to pull off two of the largest CPU transitions in history almost effortlessly. It's called fat binaries or in Apple's world, universal binary (https://en.wikipedia.org/wiki/Universal_binary https://en.wikipedia.org/wiki/Universal_binary). You don't need to ship two separate copies, you just include a target and Xcode will give you a single copy that works on two separate platforms. In addition, Microsoft is also going through the same phase with their own ARM branch of Windows 10.

by jmount 8y ago

derefr 8y ago

I would expect that Apple would bring back the Rosetta component for such cases (i.e. the same interface to the OS, but now a component doing Intel->ARM dynamic binary translation rather than PWR->Intel dynamic binary translation.) Actually, maybe dymamic binary translation wouldn't be needed all that often. A new Rosetta would likely also be helped out quite a bit by the fact that modern macOS binaries contain embedded copies of their their LLVM intermediate representation; you could transpile that IR (by patching Intel-targeted intrinsics with ARM polyfills) and then run it through the LLVM optimizer again, and then cache the result. That's a fully static binary translation, and the resulting binaries would probably be pretty fast. (You'd still need dynamic binary translation for anything with its own JIT, but maybe there are few enough programs with their own JITs—and all such programs are "big" enough in terms of development resources—that Apple can require these to ship an ARM target. In which case, maybe they don't need to build a new dynamic binary translation component at all!)

jmount 8y ago
The translation stuff may be okay for user code (and I know Apple has done it before). But for scientific code it is just too much cost and too many things to break. I know scientists are not Apple's target market, but this just makes getting a Linux laptop a much better proposition.

ttul 8y ago

If the ARM components enable a better power to weight ratio, these laptops will sell very well.

mikhailt 8y ago

> I don't see a lot of motivation for pre-compiled open source projects (such as R/CRAN) to maintain two copies of their software (one Apple AMD64 and one Apple ARM64) during the transition. Yet another thing that is going to make Macs less convenient for research and development. You might want to go look at Apple's history at how they managed to pull off two of the largest CPU transitions in history almost effortlessly. It's called fat binaries or in Apple's world, universal binary (https://en.wikipedia.org/wiki/Universal_binary https://en.wikipedia.org/wiki/Universal_binary). You don't need to ship two separate copies, you just include a target and Xcode will give you a single copy that works on two separate platforms. In addition, Microsoft is also going through the same phase with their own ARM branch of Windows 10.