Live data from Hacker News

Memory access on the Apple M1 processor

lemire.me

111–120 of 278 posts

Re: Memory access on the Apple M1 processor

#111
post #91
post #20

Earlier quoted context omitted.

This seems to be a recurring theme with the M1, and one that, in a sense, actually baffles me even more than the alternative. There is no "magic" at play here, it's just lots and lots of raw muscle. They just seem to have a freakishly successful strategy for choosing what aspects of the processor to throw that muscle at. Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What en…

> 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…

I will be honest as long apple keeps this walled garden shenanigans going. I am not buying any of their hardware.

Re: Memory access on the Apple M1 processor

#112
post #69

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.

And (genuine question) how do the Tiger Lake laptops compare with the M1 MacBooks thus far?

The outcome seems to depend greatly on the physical design of the laptops. The elsewhere-mentioned Dell XPS 13 has a particularly poor cooling design, which is why I chose the Razer Book instead. Despite being marketed in a very silly way to gamers only, it seems to have competent mechanical design.

Re: Memory access on the Apple M1 processor

#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.

Re: Memory access on the Apple M1 processor

#114
post #91
post #20

Earlier quoted context omitted.

This seems to be a recurring theme with the M1, and one that, in a sense, actually baffles me even more than the alternative. There is no "magic" at play here, it's just lots and lots of raw muscle. They just seem to have a freakishly successful strategy for choosing what aspects of the processor to throw that muscle at. Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What en…

> 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.

Re: Memory access on the Apple M1 processor

#115
post #102
post #2

Great practical information. Nice to see people who know what they are talking about putting data out there. I hope eventually these persistent HN memes about M1 memory will die: that it's "on-die" (it's not), that it's the only CPU using LPDDR4X-4267 (it's not), or that it's faster because the memory is 2mm closer to the CPU (not that either). It's faster because it has more microarchitectural resources. It can load…

>or that it's faster because the memory is 2mm closer to the CPU (not that either) Not to disagree with your overall point, but 2mm is a long way when dealing with high frequency signals. You can't just eyeball this and infer that it makes no difference to performance or power consumption.

If it works, it works. There will be no observable performance difference for DDR4 SDRAM implementations with the same timing parameters, regardless of the trace length. There are systems out there with 15cm of traces between the memory controller pins and the DRAM chips. The only thing you can say against them is they might consume more power driving that trace. But you wouldn't say they are meaningfully slower.

Re: Memory access on the Apple M1 processor

#116
post #95

Earlier quoted context omitted.

From a customer's perspective it's not my problem. Everyone had the opportunity to bid on that fab capacity and they decided not to.

Yeah, totally agreed. But if you read these comments, they seem to be in total amazement about the performance gap and not acknowledging how much of an advantage being a fab generation ahead is. Customers don't care, but discussion of the merits of the chip should be more nuanced about this. It also implies that the gap won't exist for very long, as AMD will move onto 5nm soon

> It also implies that the gap won't exist for very long, as AMD will move onto 5nm soon

... yes, if there is any capacity left. Capacity for the new process is a limited resource after all.

Re: Memory access on the Apple M1 processor

#117
post #89
post #2

Great practical information. Nice to see people who know what they are talking about putting data out there. I hope eventually these persistent HN memes about M1 memory will die: that it's "on-die" (it's not), that it's the only CPU using LPDDR4X-4267 (it's not), or that it's faster because the memory is 2mm closer to the CPU (not that either). It's faster because it has more microarchitectural resources. It can load…

The most impressive thing I've seen is that when accessed in a TLB friendly fashion that the latency is around 30ns. Anandtech has a graph showing this, specifically the R per RV prange graph. I've verified this personally with a small microbenchmark I wrote. I've not seen anything else close to this memory latency.

Sorry, what would AMD's or Intel's "latest and greatest" numbers for the same be?

Re: Memory access on the Apple M1 processor

#118
post #79

Earlier quoted context omitted.

I don't have any inside-Apple perspective, but my guess is having a tight feedback cycle between the profiles of their own software and the abilities of their own hardware has helped them greatly. The reason I think so is when I was at Google is was 7 years between when we told Intel what could be helpful, and when they shipped hardware with the feature. Also, when AMD first shipped the EPYC "Naples" it was crippled…

Interesting point. This would suggest pretty sizable synergies from the oft-rumored Microsoft acquisition of Intel.

> Microsoft acquisition of Intel

Could that possibly be approved by governments?

Re: Memory access on the Apple M1 processor

#119
post #109
post #71

Earlier quoted context omitted.

"Key Opinion Leader". I think it's the new word for "Influencer".

I am pretty sure KOL predates Influencer in modern internet usage. Before that they were simply known as Internet Celebrities. May be it is rarely used now. So apology for not explaining the acronyms.

First I've heard of it!

Re: Memory access on the Apple M1 processor

#120

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)?

There's at least two M1 optimisations targeting Apple's software stack:

1. Fast uncontended atomics. Speeds up reference counting which is used heavily by Objective-C code base (and Swift). Increase is massive comparing to Intel.

2. Guaranteed instruction ordering mode. Allows for faster Arm code to be produced by Rosetta when emulating x86. Without it emulation overhead would be much bigger (similar to what Microsoft is experiencing).

Post reply on HN