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

21–30 of 278 posts

Re: Memory access on the Apple M1 processor

#21

Post by phkahler »

djacobs7 wrote: post #15

Is the article saying that the M1 is slower than we would have expected in this case? 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. But the M1 is so parallelized that it goes to grab both arr[idx] and arr[idx+1] separately. So we have to wait for both of those two return. Meanwhile, on a less parallelized…

>> 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 consecutive addresses. If so then it looks like Apple could be missing out here.

Then again, if his array fits in cache he's just measuring instruction counts. His random indexes need to cover that whole range too. There's not enough info to figure out what's going on.

Re: Memory access on the Apple M1 processor

#22

Post by wmf »

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

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

Re: Memory access on the Apple M1 processor

#23

Post by gameswithgo »

pdpi wrote: post #20
jeffbee wrote: 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…

I see two main things behind it:

1. they are the only ones who have 5nm chips because they paid a lot to TSMC for that right 2. they gave up on expandable memory, which lets them solder it right next to the cpu, which likely makes it easier to ship with really high clocks. and/or they just spent the money it takes to get binned lpddr4 at that speed.

So a good cpu design, just like AMD and Intel have, but one generation ahead on node size, and fast ram. Its not special low latency ram or anything, just clocked higher than maybe any other production machine, though enthusiasts sometimes clock theirs higher on desktops!

Re: Memory access on the Apple M1 processor

#24

Post by gameswithgo »

jeffbee wrote: 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…

What other laptop ships with LPDDR4X clocked at 4267? I agree though that being closer to the cpu isn't having any appreciable effect on latency, but being soldered close to the cpu probably does make it easier for them to hit that high clock rate.

Re: Memory access on the Apple M1 processor

#25

Post by jayd16 »

djacobs7 wrote: post #15

Is the article saying that the M1 is slower than we would have expected in this case? 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. But the M1 is so parallelized that it goes to grab both arr[idx] and arr[idx+1] separately. So we have to wait for both of those two return. Meanwhile, on a less parallelized…

Its a little confusing because they're conflating the idea that you almost certainly read at least the entire word (and not a single byte) at a time with the other idea that you could fetch multiple words concurrently.

Re: Memory access on the Apple M1 processor

#26

Post by SekstiNi »

phkahler wrote: post #21
djacobs7 wrote: post #15

Is the article saying that the M1 is slower than we would have expected in this case? 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. But the M1 is so parallelized that it goes to grab both arr[idx] and arr[idx+1] separately. So we have to wait for both of those two return. Meanwhile, on a less parallelized…

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

Re: Memory access on the Apple M1 processor

#29

Post by wrsh07 »

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 case. While the naive model might expect cases 1 & 3 to cost the same and case 2 to cost 50% more, instead cases 2 & 3 are nearly the same (3 slightly faster) and case 2 is about 50% more expensive than 1.

Re: Memory access on the Apple M1 processor

#30

Post by whoisburbansky »

jayd16 wrote: post #27

>our naive random-memory model Doesn't everyone use the (I believe) still valid concepts of latency and bandwidth?

The concepts are still broadly valid, the naivety being referred to is the assumption that two non adjacent memory reads will be twice as slow as one memory read or two adjacent reads.
Post reply on HN