Apple M1 SoC

[M344587487]

https://www.phoronix.com/scan.php?pa...ilicon-M1-Macs

https://www.apple.com/newsroom/2020/...-unleashes-m1/

https://www.macrumors.com/2020/11/11...rst-benchmark/

Religious debates aside, what's the consensus on this chip? They've made some very dubious claims regarding performance using incredibly vague metrics that would make a politician blush, but the few benchmarks that are out are promising (at least for a low power chip focused on mobile consumption).

tl;dr they've made a 4+4 big.LITTLE chip that is very wide (taking advantage of RISC) with a very large amount of L1 and L2 cache, on a 5nm node which gives a massive advantage to their low power target. IMO mobile Zen 2 is the best x86 comparison point that exists right now because it scales well to the lower power that M1 aims for.

Being ARM, mlucas should compile and work with little to no modifications? How it performs will be interesting, particularly FFT scaling. I recall reading that it has 4x128 bit NEON SIMD units but can't find the link as yet so pinch of salt, 4x128 doesn't sound like a lot on paper but M1 should have a frequency advantage. I believe the M1 uses LPDDR4X chips with 8GB minimum, speed and bandwidth unknown. Place your bets.

[mrh]

Really looking forward to seeing how it does, especially wrt power consumption for PRP. But even the mini is too expensive, IMO, unless you have some other need for it. Can I get an M1 powered raspberry pi?

[ewmayer]

Originally Posted by M344587487

Being ARM, mlucas should compile and work with little to no modifications?

Hopefully, but only actual user testing will tell. I've no near-term plans to buy HW with one of the new Apple chips, so will rely on others for the guinea-pigging here.

Note that on my (very old, Core2Duo-based!) Macbook Classic I use clang and gcc more or less interchangeably from the command line, mostly prefer the former as it is 3-4x faster than gcc, but occasionally I need to use gcc for debugging, as clang sometimes optimizes away certain variable names even at -O0 optimization level. On my system at least, I can compile a specific sourcefile with debugging (e.g. -O0 -3 -ggdb) enabled using gcc and link together with clang-optimized-compiled .o files for the rest of the Mlucas suite, no problems -- but as I noted, this is for older OS/CPU, before Apple iOS-ified OS X and went much more walled-garden|app-store on us. Hopefully the above still holds.

[Ethan (EO)]

Anandtech ran spec2006 on an A14 - the mobile platform CPU/SOC believed to be the basis for the M1 - and it almost equals a Ryzen 9 5950x but only needs a 5W power envelope to do it, including DRAM:

https://images.anandtech.com/graphs/...226/111168.png


The M1 should be even faster.

The A14 has huge, fast L1 - 192kb L1I and 128kb L1D per big core, with 3 cycle latency on the L1D - and a unified 16MB L2 with 16 cycle latency, shared across the CPU, GPU, and accelerators. The memory space is unified across the whole platform, and the DRAM is in-package with the CPU, although it is LPDDR4x, not HBM.

Other stats are also bleeding edge - 600+ entry reorder buffer, 350+ register rename capacity, at least 7 integer, 4 L/S, and 4 FPU/SIMD execute slots, the last of which each execute 1 FMUL and 1 FADD per cycle with 4 and 3 cycle latency respectively.

(all from https://www.anandtech.com/show/16226...14-deep-dive/2)

Things should get very interesting once they start making Mx chips with faster, bigger ram and desktop power and thermals.

[rogue]

I will try to talk my wife into letting me get one in spring.

[rogue]

Originally Posted by ewmayer

Hopefully, but only actual user testing will tell. I've no near-term plans to buy HW with one of the new Apple chips, so will rely on others for the guinea-pigging here.

Note that on my (very old, Core2Duo-based!) Macbook Classic I use clang and gcc more or less interchangeably from the command line, mostly prefer the former as it is 3-4x faster than gcc, but occasionally I need to use gcc for debugging, as clang sometimes optimizes away certain variable names even at -O0 optimization level. On my system at least, I can compile a specific sourcefile with debugging (e.g. -O0 -3 -ggdb) enabled using gcc and link together with clang-optimized-compiled .o files for the rest of the Mlucas suite, no problems -- but as I noted, this is for older OS/CPU, before Apple iOS-ified OS X and went much more walled-garden|app-store on us. Hopefully the above still holds.

How hard would it be for mlucas to support primality testing of other forms, such as k*^n+/c or PRP testing of forms that do not have an efficient primality test?

[ewmayer]

Originally Posted by rogue

How hard would it be for mlucas to support primality testing of other forms, such as k*^n+/c or PRP testing of forms that do not have an efficient primality test?

Will find out if/when I ever tackle an upgrade along those lines. :)

Current focus is 100% on the 2 major items intended for the v20 release, p-1 support (first for Mersennes, later also for Fermats) and PRP-proof capability. Last month been deep in the weeds of p-1 stage 2 enhancements, using scripting (as opposed to full-blown C/assembler implementation, which is the eventual aim) to try various things.

Oh, forgot to note re. build for M1 - first thing to try would be to see if the 128-bit-SIMD precompiled binary for ARM linked at the Mlucas README works.

[ldesnogu]

Originally Posted by ewmayer

Oh, forgot to note re. build for M1 - first thing to try would be to see if the 128-bit-SIMD precompiled binary for ARM linked at the Mlucas README works.

Can OS X run Linux binaries? Because at the moment Linux isn't available (Parallel isn't out yet).

[rogue]

Originally Posted by ldesnogu

Can OS X run Linux binaries? Because at the moment Linux isn't available (Parallel isn't out yet).

No.

[ewmayer]

Originally Posted by rogue

No.

Ah, you're right, binary likely incompatible - I'm so used to building the same way on both I brain-farted re. different-OS. Build-from-scrtach it is.

BTW, this is the kind of evermore walled-garden|app-store stuff on Apple's part that concerns me:

o macOS Big Sur launch appears to cause temporary slowdown in even non-Big Sur Macs | Ars Technica

Mac users today began experiencing unexpected issues that included apps taking minutes to launch, stuttering and non-responsiveness throughout macOS, and other problems. The issues seemed to begin close to the time when Apple began rolling out the new version of macOS, Big Sur—but it affected users of other versions of macOS, like Catalina and Mojave… It didn’t take long for some Mac users to note that trustd—a macOS process responsible for checking with Apple’s servers to confirm that an app is notarized—was attempting to contact a host named ocsp.apple.com but failing repeatedly. This resulted in systemwide slowdowns as apps attempted to launch, among other things.

Related: a PDF, Reflections on trusting trustd.

o Your Computer Isn’t Yours | Jeffrey Paul:

On modern versions of macOS, you simply can’t power on your computer, launch a text editor or eBook reader, and write or read, without a log of your activity being transmitted and stored…. It turns out that in the current version of the macOS, the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it. Lots of people didn’t realize this, because it’s silent and invisible and it fails instantly and gracefully when you’re offline, but today the server got really slow and it didn’t hit the fail-fast code path, and everyone’s apps failed to open if they were connected to the internet.
...
Those shiny new Apple Silicon macs that Apple just announced, three times faster and 50% more battery life? They won’t run any OS before Big Sur.

These machines are the first general purpose computers ever where you have to make an exclusive choice: you can have a fast and efficient machine, or you can have a private one. (Apple mobile devices have already been this way for several years.) Short of using an external network filtering device like a travel/vpn router that you can totally control, there will be no way to boot any OS on the new Apple Silicon macs that won’t phone home, and you can’t modify the OS to prevent this (or they won’t boot at all, due to hardware-based cryptographic protections).
...
The day that [Richard] Stallman and [Cory] Doctorow have been warning us about has arrived this week. It’s been a slow and gradual process, but we are finally here.

[M344587487]

https://www.anandtech.com/print/1625...pple-m1-tested


Memory bandwidth looks very nice, maybe in a generation or two they might add enough cores to make compute more viable. Power draw is high, possibly way higher than the SoC can make efficient use of, so I'm not entirely sure how to interpret the figures. Comparing to the 4800u which is in a much more efficient state seems disingenuous, comparing to the 4900HS makes more sense even though ideally you'd run both efficiently and knock a small percentage off the figures. The GPU looks nice, I wonder what GPGPU APIs Apple has neglected to kill as yet.