Earlier quoted context omitted.
As WMF mentions, Tiger Lake laptops like my Razer Book have the same memory. It is not appreciably closer to the CPU in the Apple design. In Intel's Tiger Lake reference designs the memory is also in two chips that are mounted right next to the CPU.
Mind running a memory latency benchmark on your Razer Book? Does it run linux by chance?
Memory access on the Apple M1 processor
171–180 of 278 posts
Re: Memory access on the Apple M1 processor
#172Earlier quoted context omitted.
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…
The Ryzen 5950x has 135 watt TDP in actual use. That’s roughly 8x the M1.
https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...
And Ryzen chips are offered with more cores, but that’s an extremely temporary advantage (reminds me of the friend who told me not to buy Apple stock because they didn’t have big screen phones).
When Apple fits 32 Firestorm cores in a 135 watt TDP package, AMD isn’t going to have an answer.
Re: Memory access on the Apple M1 processor
#173Earlier 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…
Apple M1 is fully optimized for efficiency because it's delivered from mobile SoC and still aimed for portable laptop, meanwhile Zen3 (or Willow Cove) arch is aimed for all laptop/desktop/server category so they optimized for both efficiency and max performance.
Even though M1 is designed for efficiency, it sometimes outperforms AMD/Intel for performance. That confuses the story.
Re: Memory access on the Apple M1 processor
#174Earlier quoted context omitted.
Not yet, at least :) _mach_absolute_time: 00000000000012ec pushq %rbp 00000000000012ed movq %rsp, %rbp 00000000000012f0 movabsq $0x7fffffe00050, %rsi ## imm = 0x7FFFFFE00050 00000000000012fa movl 0x18(%rsi), %r8d 00000000000012fe testl %r8d, %r8d 0000000000001301 je 0x12fa 0000000000001303 lfence 0000000000001306 rdtsc 0000000000001308 lfence 000000000000130b shlq $0x20, %rdx 000000000000130f orq %rdx, %rax 000000000…
That may be the result of inlining clock_gettime, though that would imply a pretty different implementation from the one I am familiar with. AFAIR on x86 a locked rdtsc is ~20 cycles. So to answer the gp question, it has around a precision in the few nanoseconds range. Accuracy is a different question, IE compare numbers from the same die, but be a little more suspicious across dies. No clue how this is implemented o…
I was actually misremembering a bit.
Sufficiently old versions of mach_absolute_time used a function called clock_get_time() on i386 (if the COMM_PAGE_VERSION was not 1). This changed in macOS 10.5 to a tiny bit of assembly that just read from _COMM_PAGE_NANOTIME on i386/x86_64/ppc (the arm implementation(!!) triggers a software interrupt). The i386/x86_64/ppc definitions were also copied into xnu.
For the next few years it kind of bounced back and forth between libc and xnu, and the routine was complicated by adding timebase conversion as needed. And at some point arm support was added back (it vanished when it first went to xnu), but this time using the commpage if possible.
As for M1, I assume it's using the arm64 routine in xnu, which can be found at https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/....
As for clock_gettime_nsec_np(), at least as of Big Sur, it's in libc¹ instead of xnu and defers to mach_continuous_time()/mach_continuous_approximate_time()/mach_absolute_time()/mach_approximate_time() for the CLOCK__RAW[_] clocks. And clock_gettime() for those clocks is implemented in terms of clock_gettime_nsec_np().
¹https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen...
Re: Memory access on the Apple M1 processor
#175Earlier quoted context omitted.
It seems like Apple listened when people talked about how all modern processors bottleneck on memory access and decided to focus heavily on getting those numbers better. Of course this leads to the question that if everyone in the industry knew this was the issue why weren't Intel and AMD pushing harder on it? They already both moved the memory controller onboard so they had the opportunity to aggressively optimize i…
My guess is it had to do with limitations tied to the x86_64 instruction set. It doesn't matter how much modifications you do, if you don't start with a good foundation, you're going to be limited to that foundation.
I think the current consensus among experts is that the instruction set is not the limiting factor. Modern x64 microprocessors have a separate front-end that handles instruction decoding. These instructions are decoded to internal proprietary "micro-ops". The internal buffers and actual execution units see only these µops. One can measure where the bottlenecks are, and it's rare to find that the front-end is the bottleneck. While it's arguably true that x64 is a poorly designed "foundation", it's unlikely to be causing any performance difference here.
Re: Memory access on the Apple M1 processor
#176Earlier quoted context omitted.
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 c…
I haven't worked at Apple in almost 5 years so I can't speak to more recent developments unfortunately. libdispatch integration may be trickier & have implementation details not suitable for a public API.
Specifically if I recall correctly the internal representation of time only allowed for 2 formats (wallclock vs monotonic). I suspect adding other types of clocks could pose back/forward compat challenges. However, this is a wild shot in the dark & I didn't really look into the internals of libdispatch. Maybe ask on their github page?
Generally upgrading a private API to public is a lot of work & goes through a lot of review (having monitored that mailing list & added 1 API during my time there). So if there's a private API probably some team at Apple needed it to deliver a feature but the maintainers were not confident the specific solution they chose generalized well & either requires some work or something else.
Re: Memory access on the Apple M1 processor
#177Earlier quoted context omitted.
> Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What enabled/led them to make those choices where others haven't? The things people give them complains about: (a) keeping a walled garden, (b) moving fast and taking the platform to new directions all at once (c) controlling the whole stack Which means they're not beholden to compatibility with third party frameworks and big…
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.
"A" does matter a bit. Builds are uploaded to the App Store include bitcode, which Apple strips on distribution.
According to docs, enabling bitcode: "Includes bitcode which allows the App Store to compile your app optimized for the target devices and operating system versions, and may recompile it later to take advantage of specific hardware, software, or compiler changes."
It seems quite likely they have (and probably used) the capability to recompile any app on their platform to benchmark real workloads against prototype silicon changes.
Re: Memory access on the Apple M1 processor
#178Earlier quoted context omitted.
One core of the M1 can drive the memory subsystem to the rails. A single core can copy (load+store) at 60GB/s. This is close to the theoretical design limit for DDR4X. A single core on Tiger Lake can only hit about 34GB/s, and Skylake-SP only gets about 15GB/s. So yes, it is close to 4x faster.
Thanks for clarifying. But this isn't any fundamental difference IMO. There isn't any functional limitation in an Intel core that means it cannot saturate the memory bandwidth from a single core, unless I am missing something.
One could argue that it's not "fundamental", but it's definitely a functional limitation of the current Intel cores. The memory bandwidth of a single core is hardware limited by the number "Line Fill Buffers". Each buffer keeps track of one outstanding L1 cacheline miss, thus the number of LFB's limits the memory level parallelism (MLP). "Little's Law" gives the relationship between the latency, outstanding requests, and throughput. With 10 LFB's and the current latency of memory, it's physically impossible for a single core to use all available memory bandwidth, especially on machines with more than 2 memory channels.
The M1 chip allows higher MLP, presumably because it has more LFB's per core (or maybe they are using different approach where the LFB's are not per-core?). I apologize for using so many abbreviations. I searched to try to find a better intro, but didn't find anything perfect. I did come across this thread that (apparently) I started several years ago at the point where I was trying to understand what was happening: https://community.intel.com/t5/Software-Tuning-Performance/S....
Re: Memory access on the Apple M1 processor
#179Re: Memory access on the Apple M1 processor
#180Earlier 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 gives you a choice of cutting power, improving performance, or some mix of the two. Apple appears to have taken the power reduction when they moved to TSMC 5nm. >The one explanation and theory I have is that Apple might have finally pulled back on their excessive peak power draw at the maximum performance states of the CPUs and GPUs, and thus peak performance wouldn’t have seen such a large jump this ge…
That seems like a pretty good trade off for mobile devices. They usually don’t have sustained performance needs, you aren’t going to render a movie or do other long running computational tasks. But mobile has a lot of bursty power demands: Launch dozens of app many times a day for example. You want your short-ish interactions with your phone to be snappy.