Apples new M1 microprocessor

[bd139]

I'm slightly disappointed -O3 didn't optimise it to a nop or something and then amble off with its chest puffed up like a pigeon. clang/llvm is definitely more predictable than GCC.

[magic]

This junk will be removed if you mark it static so that it's inaccessible to any external code linked against the resulting object file.
Otherwise such "optimization" would not be legal.
Alternatively, add a main function, compile with -flto and do the final link.

[bw2341]

The rosetta version *did* run 10% faster than the native version (wall clock time), even including translation overhead, and got the same printed results. There's no arguing against that.

This is all far beyond my knowledge, but I did read of an Apple Silicon feature that may relate to this result.

Intel processors have a strong memory ordering model that adds implicit memory barriers. ARM processors have a weaker memory ordering model to allow more reordering for better performance. This would make Rosetta performance terrible if it needed to emulate this behaviour with additional barrier instructions to accurately emulate an Intel processor.

To solve this, Apple built a TSO (Total Store Ordering) mode that changes the processor’s memory ordering model to be similar to Intel’s. This allows Rosetta to translate x86-64 load and store instructions to ARM directly.

It seems that TSO mode may only be available on the high performance Firestorm cores. Perhaps the ARM version started on the low power cores and was moved to the high performance cores. Is there a way to force the program to run on the high performance cores?

If the Rosetta version can only run on the high performance cores, this may explain the speed discrepancy.

[Cerebus]

This junk will be removed if you mark it static so that it's inaccessible to any external code linked against the resulting object file.
Otherwise such "optimization" would not be legal.
Alternatively, add a main function, compile with -flto and do the final link.

*ahem*

...as close to optimal as you can get without global optimization (where hopefully the compiler would work out that this loop produces a value that is never used anywhere else and elide all of this).

[magic]

Apple built a TSO (Total Store Ordering) mode that changes the processor’s memory ordering model to be similar to Intel’s. This allows Rosetta to translate x86-64 load and store instructions to ARM directly.

There is speculation that they needed to do something like that to achieve compatibility, but has it been confirmed with any sort of detail and accuracy?

*ahem*

Just responding to bd139's disappointment

[brucehoult]

The rosetta version *did* run 10% faster than the native version (wall clock time), even including translation overhead, and got the same printed results. There's no arguing against that.

This is all far beyond my knowledge, but I did read of an Apple Silicon feature that may relate to this result.

Intel processors have a strong memory ordering model that adds implicit memory barriers. ARM processors have a weaker memory ordering model to allow more reordering for better performance. This would make Rosetta performance terrible if it needed to emulate this behaviour with additional barrier instructions to accurately emulate an Intel processor.

To solve this, Apple built a TSO (Total Store Ordering) mode that changes the processor’s memory ordering model to be similar to Intel’s. This allows Rosetta to translate x86-64 load and store instructions to ARM directly.

This is a fairly obvious idea -- obvious enough that RISC-V started the process to add it as an option about 3 1/2 years ago and ratified it as a standard in July 2018.

You can build compliant RISC-V cores that use RVWMO (RISC-V Weak Memory Ordering, which is actually somewhat stronger than ARM's, but still allows high performance) or RVTSO (RISC-V Total Store Ordering), or that are switchable between the two.

Software written for RVWMO will run correctly on any CPU or mode, but may run somewhat slower is TSO is enabled. Software written for RVTSO must run on a CPU implementing RVTSO full-time on in RVTSO mode on a CPU that is switchable.

RVWMO was designed by a panel of world experts on memory consistency after bugs were found in the original RISC-V memory consistency specification in 2016.

Here's a discussion presentation from mid 2017, with a lot of background: https://www.bsc.es/sites/default/files/public/u1810/arvind_0.pdf

And a status update at the end of 2017 https://riscv.org/wp-content/uploads/2017/12/Tue0954-RISC-V_Memory_Model-Lustig.pdf

It seems that TSO mode may only be available on the high performance Firestorm cores. Perhaps the ARM version started on the low power cores and was moved to the high performance cores. Is there a way to force the program to run on the high performance cores?

If the Rosetta version can only run on the high performance cores, this may explain the speed discrepancy.

I have no idea about a difference in the cores, but any program that runs CPU-bound for more than maybe 100mS (or even 1mS?) causes a transition to a high performance core.

[bd139]

Interesting with the core transition. I assume that's going to have some consequences on spikey loads. It'll get evicted off a low power core, blowing the cache closest to the CPU in time to stop doing what it was doing. Wonder if there is any affinity and core pinning support on macOS...

Haven't had a lot of time over the last few days to play with this machine yet apart from as a luser

[DiTBho]

Here's a discussion presentation from mid 2017, with a lot of background: https://www.bsc.es/sites/default/files/public/u1810/arvind_0.pdf

And a status update at the end of 2017 https://riscv.org/wp-content/uploads/2017/12/Tue0954-RISC-V_Memory_Model-Lustig.pdf

Thanks for this, it's very useful for me.

[Cerebus]

Interesting with the core transition. I assume that's going to have some consequences on spikey loads. It'll get evicted off a low power core, blowing the cache closest to the CPU in time to stop doing what it was doing. Wonder if there is any affinity and core pinning support on macOS...

Haven't had a lot of time over the last few days to play with this machine yet apart from as a luser

[Part of] the cache is shown hanging off the switch fabric. Quite which side of the fabric/CPU core interface which level of cache sits at is opaque, but it ought to go some way to alleviating the cache bashing cost of switching cores.

[bd139]

Yeah it'll still have to blow away some L1 / I/D cache I imagine. Not sure what the cache topology is. I haven't taken the CPU to bits yet in my mind. There are big gains to be had keeping cache as local as possible and for as long as possible.

Actually that last point reminds me how much I hate virtualization as a concept

Edit: found one defect. When I shut the M1 Mini down, it crashes on shutdown and reboots and then I have to shut it down again. Sure they will fix that in macOS 11.1.

[nfmax]

defect. When I shut the M1 Mini down, it crashes on shutdown and reboots and then I have to shut it down again. Sure they will fix that in macOS 11.1.

"They all do that sir" - specifically my 2018 Intel mini does, since a security update to Mojave. It got a lot less frequent when I finally upgraded to Catalina, and it is supposed to be *fixed* in Big Suck Sur. Something to do with the BridgeOS code running on the secure enclave processor. It sounds like M1 minis may have this too

[olkipukki]

Meanwhile, if you already missed Mac mini on Intel, you don't need to buy it anymore, just "rent" from AWS 

"Customers can connect to Mac instances via both SSH for Command Line Interface and active remote screen sharing using a VNC client for a graphical interface. " 

[bd139]

defect. When I shut the M1 Mini down, it crashes on shutdown and reboots and then I have to shut it down again. Sure they will fix that in macOS 11.1.

"They all do that sir" - specifically my 2018 Intel mini does, since a security update to Mojave. It got a lot less frequent when I finally upgraded to Catalina, and it is supposed to be *fixed* in Big Suck Sur. Something to do with the BridgeOS code running on the secure enclave processor. It sounds like M1 minis may have this too

Yeah my 2018 i3 one did that as well so could be right there.

Interestingly I just found another bloody bug in it. Safari 14 in 11.0.1 uses macOS 10.15.6 as the user agent. Have raised this with WebKit, was marked as a duplicate of an existing bug where they manually set it to 10.15.7 as a solution . This is apparently because user agent sniffing problems on some libraries or web sites. Double 

Meanwhile, if you already missed Mac mini on Intel, you don't need to buy it anymore, just "rent" from AWS 

"Customers can connect to Mac instances via both SSH for Command Line Interface and active remote screen sharing using a VNC client for a graphical interface. " 

Minimum 24 hours rental on that which is ridiculous if you want to do a short compile run on it or some CI stuff and/or shut it down overnight to save some cash.

[brucehoult]

Meanwhile, if you already missed Mac mini on Intel, you don't need to buy it anymore, just "rent" from AWS 

"Customers can connect to Mac instances via both SSH for Command Line Interface and active remote screen sharing using a VNC client for a graphical interface. " 

Yup, for around $780 a month.

You could buy a new one every month! Or rent one at other colo places for a lot less e.g. https://www.macminivault.com/dedicated-sign-up/

[bd139]

Exactly. They ripped the guys responsible for this a new asshole on hacker news about it 

Edit: fixed the crash in macOS. It was not macOS but after doing some googling it was Karabiner-Elements doing it. I removed that and worked out how to get it to behave with an ISO layout keyboard by default and it's sorted now. One less headache!

[madires]

New RISC-V CPU claims recordbreaking performance per watt: https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/

200 mW at 4.25 GHz, and 69 mW at 3 GHz!

[Marco]

I find the hemming and hawing about the M1 power consumption funny. Must not upset the fanboys.

Not just here, but in general the performance and power efficiency of Zen2 laptop processors in parallel benchmarks really calls into question the supposed extra-ordinary performance of the M1 architecture. Apple is really good at scale and could afford to just outright buy 6 months of 5nm production at relatively high risk, architecturally ... well it's impressive they closed the gap this well, but with the node advantage talking about superiority is a bit presumptuous.

[bd139]

I think the point is if you crank a zen2 laptop and an M1 up on the same workload then the job will probably finish about the same time but the Mac will not burn your dick off or need plugging in.

[Marco]

My point is that that's wishful thinking rather than reality, or in other words ... inside the reality distortion field

Cheering Apple and helping them getting a computing monopoly is a bad idea for anyone who loves technology in the first place, but to also applaud their supposed massive architectural superiority is just ignorant. Microsoft is incompetent, Intel can't do EUV and AMD doesn't have the ability to compete with Apple for node access ... x86 processor architectures are currently clearly not the source of the problem with PCs though, it's everything else. Unfortunately, because the relative openness of the PC gave us a golden age. Now Apple is going to "correct" IBM's mistake and make it all boring.

[bd139]

It’s not a computing monopoly at 15% market share...

The reason the PC problems exist is because there is almost zero vertical integration. And the fact the entire industry has been a race to the bottom built on the ashes of a lot of really bad computing decisions (NT for example). As someone who came from the old workstation background (Sun in particular) all we’re doing is buying a nicely vendor integrated Unix here with a desktop that’s better than CDE. Which is what you do if you want something that works.

All of this is moot though. The thing that is costly is my time and attention. Anything which gets the fuck out of my way and let’s me solve problems gets the job. That varies depending on what’s required at the time and what it is doesn’t really bother me.

[Marco]

It’s not a computing monopoly at 15% market share...

It's going to snowball.

The openness of the PC always opened companies up a little more to competition, Intel/Microsoft could take leads but especially for Microsoft there was always a relatively low cost path for competition (which Apple massively benefited from). An Apple lead will now start taking away investment from PC hardware development, if they get sufficient mass it's all over and it will be infinitely harder to dislodge. Boring.

[bd139]

ARM and RISC-V are open as well. This is just one variation of the arm64 platform 

None of that matters though. The contract between your data and the system is where you should be concerned.

[Marco]

ARM and RISC-V are open as well. This is just one variation of the arm64 platform

M1 architectural innovation don't cheaply stream into ARM/RISC-V from other companies.

x86 architectural innovation streamed cheaply into Macs as long as Apple still needed it.

[bd139]

Well it does really. It’s no secret what they did. Most of this thread is about it.

x86 is dying. They pushed it to the limit already. Someone just put another option on the table, that’s all.

[Marco]

Well it does really. It’s no secret what they did.

State of the art 8-way superscalar processors without running into a million patents are billion dollar endeavours, M1 does nothing to make this easier for ARM/RISC-V implementations from other companies ... it doesn't even help create a market for them, unlike how things happened on PCs. Boring.

x86 is dying.

X86 is fine for PCs, if they were at the same node 4800U would almost certainly scale higher in performance within a 15 Watt envelope (and be the same die size as a M1). PCs, even laptops, don't scale low enough in power consumption for little cores to be truly necessary. That display is pushing out nits any way.

PCs are dying because of everything else, M1 is nothing special architecturally compared to x86 ... just other ARM processors.