Live data from Hacker News

Memory access on the Apple M1 processor

lemire.me

51–60 of 278 posts

Re: Memory access on the Apple M1 processor

#51
post #40
post #29

Ok, summary: This article lays out three scenarios: 1) accessing two random elements 2) accessing 3 random elements 3) accessing two pairs of adjacent elements (same as (1) but also the elements after each random element) It then does some trivial math to use the loaded data. A naive model might only consider memory accesses and might assume accessing an adjacent element is free. On the Mac m1 core, this is not the c…

I don't really understand the comparison because it seems like scenario 3 (2+) is doing more XORs and twice the accesses to array over the same amount of iterations. We have to assume these are byte arrays, yes? Or at least some size that's smaller than the cache line. You would still pay for the extra unaligned fetches. I don't think this is a valid scenario at all, M1 or not. Anyone want to run these tests on an In…

The point of the naive model is that you assume memory accesses dominate

That is, the math part is so trivial compared to the memory access that you could do a bunch of math and you would still only notice a change in the number of memory accesses.

Also it looks like the response to yours links their test and the naive model predicts correctly

Re: Memory access on the Apple M1 processor

#52
post #22

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

No, there's no cross-stack optimization here. The M1 gives very high performance for all code.

I think this gets lost in the fray between the "omg this is magic" and then the Apple haters. The M1 is a very good chip. Apple has hired an amazing team and resourced them well. But from a pure hardware perspective, the M1 is quite evolutionary. However the whole Apple Silicon experience is revolutionary and magical due to the tight software pairing.

Both teams deserve huge praise for the tight coordination and unreal execution.

Re: Memory access on the Apple M1 processor

#53
post #20
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…

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…

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

There is no freakishly successful strategy at play there as well. It's just all previous attempts at "fast ARM" chip were rather half hearted "add a pipeline step there, add extra register there, increase datapath width there," and not to squeeze it to the limit.

Re: Memory access on the Apple M1 processor

#54
post #45
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…

>HN memes about M1 memory will die It is not only HN. It is practically the whole Internet. Go around the Top 20 hardware and Apple website forum and you see the same thing, also vastly amplify by a few KOL on twitter. I dont remember I have ever seen anything quite like it in tech circle. People were happily running around spreading misinformation.

What is a KOL?

Re: Memory access on the Apple M1 processor

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

In other words, it’s better architecture. If anything this makes it seem more impressive to me.

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.

Re: Memory access on the Apple M1 processor

#56

Earlier quoted context omitted.

> There's not enough info to figure out what's going on. If you only look at the article this is true. However, the source code is freely available: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

I ran the benchmark on my system It's a 6 years old system, fastest times are in the 25ns range - 2-wise+ is 5% slower than 2-wise - 3-wise is 46% slower than 2-wise - 3-wise is 39% slower than 2-wise+ on the M1 - 2-wise+ is 40% slower than 2-wise - 3-wise is 46% slower than 2-wise - 3-wise is 4% slower than 2-wise+

Interesting, I ran it on my laptop (i7-7700HQ) with the following results:

- 2-wise+ is 19% slower than 2-wise

- 3-wise is 48% slower than 2-wise

- 3-wise is 25% slower than 2-wise+

However, as mentioned in the post the numbers can vary a lot, and I noticed a maximum run-to-run difference of 23ms on two-wise.

Re: Memory access on the Apple M1 processor

#57
post #31

Earlier quoted context omitted.

> it can do with a single core what an Intel part needs all cores to accomplish. Care to explain what you mean specifically by this?

The M1 has extremely high single-core performance.

It is not 4 times faster than an Intel core, though...

Re: Memory access on the Apple M1 processor

#58
post #20
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…

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…

Apple has been iterating on their proprietary mobile ARM-based processors since 2010, and has gotten really good at it. I would imagine that producing billions of consumer devices with these chips has helped give them a lot of experience in shortened time frame.

I also wonder if having the hardware and software both worked on in-house is an advantage. I mean, if you're developing power management software for a mobile OS, and you're using a 3rd-party vendor, then you read the documentation, and work with the vendor if you have questions. If it's all internal, you call them, and could make suggestions on future processor design too based on OS usage statistics and metrics.

Re: Memory access on the Apple M1 processor

#59

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…

> There's not enough info to figure out what's going on. If you only look at the article this is true. However, the source code is freely available: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

TLDR: he is using a random index with a big enough array
Post reply on HN