Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory access on the Apple M1 processor

lemire.me

Post reply on HN
Print view View original

161–170 of 278 posts

Re: Memory access on the Apple M1 processor

#161

Post by alblue »

waterside81 wrote: post #13

For people who know more about this stuff than me: are these sorts optimizations only possible because Apple controls the whole stack and can make the hardware & OS/software perfectly match up with one another or is this something that Intel can do but doesn't for some reasons (tradeoffs)?

Sort of; Intel and AMD are stuck with the variable width instruction isa that exists due to historical evolution. To do something different you need a new isa.

Intel tried this with Itanium a while back and failed because it is difficult to get software developers to target a new isa and provide compilers and compiled code for everything unless you use a translation layer.

Apple is one step ahead here because their compilers already supported ARM isa (because iPhones use them) and had both the OS and apps ready to go from day one of availability.

They also had translation technology that would allow mutating x86_64 code to ARM64 code so that old apps would (on the whole) run acceptably fast on the new chip.

To do the latter properly, Apple had to create a special mode to run the arm chip with total store order for memory writes, which is not standard on arm. (It would be a lot slower if they didn’t have that when running Rosetta translated code.)

So both the OS being available, and the OS influencing the ARM tweaks (eg TSO) could they pull it off.

They also have the position that they build hardware that uses those chips so can mass produce - and in fact, replace - existing hardware.

Each of these things could be done in isolation by Intel/Windows/Apps but it would be difficult to do all three.

Even getting JavaScript maths in a special instruction was difficult enough on Intel, and that was something of benefit to any browser.

My guess is you’ll see Intel and AMD offering Arm chips in the near future, as both AWS (graviton) and Apple have shown the way to a new ARM future.

Re: Memory access on the Apple M1 processor

#162

Post by gameswithgo »

willvarfar wrote: post #113

A lot of commenters here are saying that Apples advantage is that it can profile the real workloads and optimise for that. Well that’s true and could very well be an advantage. An advantage in that they did it, not in that only they have access to it. Intel and AMD can trivially profile real world workloads too. Did they? I don’t know what Apple did, but the impression I get is that intel certainly hasn’t.

of course every cpu designer is using real world workloads to guide design

Re: Memory access on the Apple M1 processor

#163

Post by lilyball »

vlovich123 wrote: post #64
lilyball wrote: post #14

Earlier quoted context omitted.

It was added some years ago, and I believe mach_absolute_time is actually now implemented in terms of (the implementation of) clock_gettime. The documentation on mach_absolute_time now even says you should use clock_gettime_nsec_np(CLOCK_UPTIME_RAW) instead. macOS also has clock constants for a monotonic clock that increases while sleeping (unlike CLOCK_UPTIME_RAW and mach_absolute_time).

I was part of the team that really pushed the kernel team to add support for a monotonic clock that counts while sleeping (this had been a persistent ask before just not prioritized). We got it in for iOS 8 or 9. The dance you otherwise have to do is not only complicated in userspace on MacOS, it's expensive & full of footguns due to race conditions (& requires changing the clock basis for your entire app if I recall…

Do you have any insight as to why libdispatch added support for this new clock internally (in the last year or two), but did not expose it in any public API? In C I can manually construct a dispatch_time_t that will use make libdispatch use CLOCK_MONOTONIC_RAW¹, if I'm willing to make assumptions about the format of dispatch_time_t² (despite libdispatch warning that the internal format is subject to change³). And I can't even do this in Swift. It would be really useful to have this functionality, so I'm mystified as to why it's hidden.

¹Technically it uses mach_continuous_time() first if available (which appears to be equivalent to CLOCK_MONOTONIC_RAW), then clock_gettime(CLOCK_BOOTTIME, &ts) on Linux, then clock_gettime(CLOCK_MONOTONIC, &ts), then some other API for Windows.

²Conveniently enough the value that is equivalent to DISPATCH_TIME_NOW using the monotonic clock is just INT64_MIN, at least in the current encoding.

³Swift makes assumptions about the internal format of dispatch_time_t so I don't know if it actually can meaningfully change. Newer versions of Swift now use stdlib on the system, but any app built with a sufficiently old version of Swift still embeds its own copy of the stdlib. Granted, additions (like the monotonic clock) should be fine, as the Swift API does not actually bridge from dispatch_time_t so it only ends up representing times it has APIs to construct. Since it doesn't have APIs to construct monotonic times, they won't break it.

Re: Memory access on the Apple M1 processor

#164

Post by GeekyBear »

valuearb wrote: post #157
adam_arthur wrote: post #94

Earlier quoted context omitted.

Certainly Apple's processors are far ahead, but they're a full process generation (5nm) ahead of their competitors. They paid their way to that exclusive right through TSMC. I'm sure they'll still come out ahead in benchmarks, but the numbers will be much closer once AMD moves to 5nm. You absolutely cannot fairly compare chips from different fab generations. I don't see many comments hammering this point home enough.…

A node shrink is going to help AMD by 15% at best, they are much farther behind than that on performance per watt. AMD has done mobile CPUs that look as if they are close to or even ahead of the M1 in performance, but they all use 2x to 4x as much power. When higher core count versions of Apple Silicon are available, they will be able to have double the core counts of AMD chips at the same power levels. And each thos…

AMD's mobile chips are still on Zen 2 cores, so they are behind the M1 on single core performance in both integer and floating point.

It's their desktop chips running Zen 3 cores that trade blows on single core integer math, depending on which benchmark you look at.

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

Of course, on multi-core performance you can buy a desktop chip with a much higher Zen 3 core count than Apple offers.

Re: Memory access on the Apple M1 processor

#165

Post by [deleted] »

paulryanrogers wrote: post #159
jeffbee wrote: post #114

Earlier quoted context omitted.

Neither A nor C makes any sense, are not supported by evidence. There is no aspect of the mac or macOS that can be realistically described as a "walled garden". It comes with a compiler toolchain and ... well, some docs. It natively runs software compiled for a foreign architecture. You can do whatever you want with it. It's pretty open. A "walled garden" is when there is a single source of software.

Running apps downloaded outside the store requires jumping through an increasing number of hoops or vendors pay to get every build signed off by a single party.

[deleted]

Re: Memory access on the Apple M1 processor

#166

Post by coldtea »

paulryanrogers wrote: post #159
jeffbee wrote: post #114

Earlier quoted context omitted.

Neither A nor C makes any sense, are not supported by evidence. There is no aspect of the mac or macOS that can be realistically described as a "walled garden". It comes with a compiler toolchain and ... well, some docs. It natively runs software compiled for a foreign architecture. You can do whatever you want with it. It's pretty open. A "walled garden" is when there is a single source of software.

Running apps downloaded outside the store requires jumping through an increasing number of hoops or vendors pay to get every build signed off by a single party.

You don't have to pay to have your apps signed off (notarized).

Re: Memory access on the Apple M1 processor

#167

Post by phkahler »

eloff wrote: post #66
phkahler wrote: post #21

Earlier quoted context omitted.

>> My understanding, based on the article, is that a normal processor, we would have expected arr[idx] + arr[idx+1] and arr[idx] to take the same amount of time. That depends. If the two accesses are on the same cache line, then yes. But since idx is random that will not happen sometimes. He never says how big array[] is in elements or what size each element is. I thought DRAM also had the ability to stream out conse…

He mentioned it's a 1GB array, and the source code is available.

That array is indexed by an array of random numbers and there are only 3M of them. That should be enough assuming even 4 bytes per index it will just fit in the 12MB cache, but then there are accesses to the big array as well.

Re: Memory access on the Apple M1 processor

#168

Post by my123 »

messe wrote: post #16
lilyball wrote: post #12

Earlier quoted context omitted.

Is it possibly exposed via sysctl, which does support a flag to list all variables?

From sysctl -a on my M1: hw.cachelinesize: 128 hw.l1icachesize: 131072 hw.l1dcachesize: 65536 hw.l2cachesize: 4194304 EDIT: also, when run under Rosetta hw.cachelinesize is halved: hw.cachelinesize: 64 hw.l1icachesize: 131072 hw.l1dcachesize: 65536 hw.l2cachesize: 4194304

sysctl on m1 contains the cache sizes for the little cores (since those are CPUs 0-3)

big cores (CPU4-7) have 192KB L1I and 128KB L1D.

Re: Memory access on the Apple M1 processor

#169

Post by ben-schaaf »

kllrnohj wrote: post #86
amelius wrote: post #55

Earlier quoted context omitted.

No, it's the same architecture but with different parameters. It's like the difference between the situation where every car uses 4 cylinders, and then Apple comes along and makes a car with 5 cylinders.

Your analogy was so close! It's Apple comes along and makes an 8 cylinder engine. Since, you know, the other CPUs are 4-wide decode and Apple's M1 is 8-wide decode :)

Zen 3 is effectively 8 wide with their micro-op cache. Intel similarly has been 6 wide for ages.

Re: Memory access on the Apple M1 processor

#170

Post by paulryanrogers »

coldtea wrote: post #166
paulryanrogers wrote: post #159

Earlier quoted context omitted.

Running apps downloaded outside the store requires jumping through an increasing number of hoops or vendors pay to get every build signed off by a single party.

You don't have to pay to have your apps signed off (notarized).

I'll have to check again because if that's the case it's still a walled garden, just with free admission.
Post reply on HN