←back to thread

Apple Silicon M1 chip in MacBook Air outperforms high-end 16-inch MacBook Pro

(www.macrumors.com)
1080 points antipaul | 3 comments | 12 Nov 20 00:56 UTC | HN request time: 0.001s | source
Show context
mcintyre1994 ◴[12 Nov 20 07:21 UTC] No.25067338[source]▶
> The M1 chip, which belongs to a MacBook Air with 8GB RAM, features a single-core score of 1687 and a multi-core score of 7433. According to the benchmark, the M1 has a 3.2GHz base frequency.

> The Mac mini with M1 chip that was benchmarked earned a single-core score of 1682 and a multi-core score of 7067.

> Update: There's also a benchmark for the 13-inch MacBook Pro with M1 chip and 16GB RAM that has a single-core score of 1714 and a multi-core score of 6802. Like the MacBook Air , it has a 3.2GHz base frequency.

So single core we have: Air 1687, Mini 1682, Pro 1714

And multi core we have: Air 7433, Mini 7067, Pro 6802

I’m not sure what to make of these scores, but it seems wrong that the Mini and Pro significantly underperform the Air in multi core. I find it hard to imagine this benchmark is going to be representative of actual usage given the way the products are positioned, which makes it hard to know how seriously to take the comparisons to other products too.

> When compared to existing devices, the M1 chip in the MacBook Air outperforms all iOS devices. For comparison's sake, the iPhone 12 Pro earned a single-core score of 1584 and a multi-core score of 3898, while the highest ranked iOS device on Geekbench's charts, the A14 iPad Air, earned a single-core score of 1585 and a multi-core score of 4647.

This seems a bit odd too - the A14 iPad Air outperforms all iPad Pro devices?

replies(14): >>25067412 #>>25067414 #>>25067435 #>>25067467 #>>25067719 #>>25067879 #>>25067931 #>>25068427 #>>25068698 #>>25068977 #>>25069217 #>>25069354 #>>25070019 #>>25071266 #
throwaway4good ◴[12 Nov 20 08:30 UTC] No.25067719[source]▶
The results seem a little weird but if remotely true then these machines are going to sell like cup cakes.

Why would anyone (who is not forced) buy an Intel PC laptop when these are available and priced as competitive as they are?

replies(19): >>25067752 #>>25067760 #>>25067775 #>>25067789 #>>25067856 #>>25067866 #>>25067936 #>>25067945 #>>25067976 #>>25068118 #>>25068189 #>>25068589 #>>25068695 #>>25068781 #>>25069148 #>>25070670 #>>25071421 #>>25072755 #>>25074611 #
marcan_42 ◴[12 Nov 20 11:44 UTC] No.25068781[source]▶
Until all software is ported to ARM, it will run in emulation, which is going to be slower in most cases. People invested in plug-in ecosystems, like DAWs or video editing, will likely have an endless long tail of plug-ins that aren't getting ported, or that require a re-purchase to get an ARM version. And due to Rosetta's architecture, you can't mix ARM and x86 plug-ins (in-process, like VSTs - Apple wants you to use AUv3 which is out of process but nobody does that), so you will be running your entire workflow under emulation until you can make the switch hard and all at once. And some of your software will never make it.

Mark my words, this is going to be a massive shit show for people using those ecosystems, for 5 years if not 10. It already happened with the PPC transition.

replies(3): >>25069378 #>>25070689 #>>25071786 #
valuearb ◴[12 Nov 20 16:58 UTC] No.25071786[source]▶
Rosetta2 is mind blowing.

“ fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1”

https://mobile.twitter.com/hhariri/status/132678854650246349...

“…and ~14 nanoseconds on an M1 emulating an Intel”

replies(1): >>25072897 #
1. marcan_42 ◴[12 Nov 20 18:22 UTC] No.25072897{3}[source]▶
How does it handle DSP inner loops? SIMD? x87 code? Floating point corner cases like denormals? What about the inevitable cases where impedance mismatch between the architectures causes severe performance loss? Is Rosetta2 binary translated code guaranteed to be realtime-safe if the original code was? What about the JIT? There's no way that is realtime-safe. What happens if some realtime code triggers the JIT?

We still can't emulate some 20-year-old machines at full speed on modern hardware due to platform impedance mismatches. Rosetta2 may be good, but until someone runs a DAW on there with a pile of plug-ins and shows a significant performance gain over contemporary Intels (and zero unexpected dropouts), I'm not buying the story of Rosetta2 amazingness.

replies(1): >>25073616 #
2. valuearb ◴[12 Nov 20 19:11 UTC] No.25073616[source]▶
Rosetta2 is not emulation.

Edit: And Apple has already discussed how Rosetta2 handles complexities like self modifying code. It probably won’t help with performance but the M1 has a lot of power to keep even that code running fast.

But more importantly video/audio apps aren’t going to be using Rosetta2 for very long. 99% of code written for x86 MacOS is going to be a simple recompile to native, if not more. Not going native when your competitors did and got 2-5x faster is corporate suicide.

replies(1): >>25077405 #
3. marcan_42 ◴[13 Nov 20 00:45 UTC] No.25077405[source]▶
Rosetta2 is emulation just as much as qemu and Dolphin are emulation, both of which also use binary translation like every other modern emulator. Apple marketing just doesn't want you to call Rosetta2 an emulator because "emulators are slow". Anything running software on a different architecture is an emulator.

If you read my parent comment you'll see how DAWs are going to be using Rosetta2 for years to come, maybe even a decade, for many people. Even if there are ARM versions, you won't be able to use them until all your dozens if not hundreds of plug-ins, some of which won't be actively developed any more or will require a re-purchase for an ARM version, have also migrated.

People invested in such ecosystems aren't just going to up and give up half their collection of software, or spend thousands re-purchasing upgrades to get ARM versions.