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

41–50 of 278 posts

Re: Memory access on the Apple M1 processor

#41

Post by [deleted] »

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…

[deleted]

Re: Memory access on the Apple M1 processor

#42

Post by africanboy »

jayd16 wrote: post #40
wrsh07 wrote: 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…

I did it on an old i7 laptop

https://news.ycombinator.com/item?id=25661055

Re: Memory access on the Apple M1 processor

#43

Post by AnthonyMouse »

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

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

Interestingly it's the other way around. Apple is using TSMC's 5nm process (they don't have their own fabs), which is better than Intel's in-house fabs, so it's Intel's vertical integration which is hurting them compared to the non-vertically integrated Apple.

Also, the answer to "is this only possible because of vertical integration" is always no. Intel and Microsoft regularly coordinate to make hardware and software work together. Intel is one of the largest contributors to the Linux kernel, even though they don't "own" it. Two companies coordinating with one another can do anything they could do as an individual company.

Sometimes the efficiency of this is lower because there are communication barriers and isn't a single chain of command. But sometimes it's higher because you don't have internal politics screwing everything up when the designers would be happy with outsourcing to TSMC because they have a competitive advantage, but the common CEO knows that would enrich a competitor and trash their internal investment in their own fabs, and forces the decision that leads to less competitive products.

Re: Memory access on the Apple M1 processor

#44

Post by jayd16 »

duskwuff wrote: post #32
jayd16 wrote: post #25

Earlier quoted context omitted.

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.

Any cached memory access is going to read in the entire cache line -- 64 bytes on x86, apparently 128 on M1. This is true across most architectures which use caches; it isn't specific to M1 or ARM.

Yes almost certainly more than the word will be read but it varies by architecture. I would think almost by definition no less than a word can be read so I went with that in my explanation.

Re: Memory access on the Apple M1 processor

#45

Post by ksec »

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…

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

Re: Memory access on the Apple M1 processor

#46

Post by mhh__ »

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 think it's worth saying that because AMD have only just really hit their stride, Intel were under almost zero pressure to improve which has really hurt them especially with the process.

X86 is definitely a coefficient overhead, but if Intel put their designs on 5nm they'd look pretty good too - Jim Keller (when he was still there) hinted their offerings for a year or so in the future are significantly bigger to the point of him judging it to be worth mentioning so I wouldn't write them off.

Re: Memory access on the Apple M1 processor

#47

Post by [deleted] »

Nokinside wrote: post #33
messe wrote: post #16

Earlier quoted context omitted.

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

M1 cache lines are double of what is commonly used by Intel, AMD and other ARM microarchtectures use. That's significant difference.

[deleted]

Re: Memory access on the Apple M1 processor

#48

Post by sroussey »

jayd16 wrote: post #27

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

Depends on context.

For example, what is the bandwidth and latency when you ask for the value at the same memory address in an infinite loop? And how does that compare to the latency and bandwidth of a memory module you buy on NewEgg?

Re: Memory access on the Apple M1 processor

#49

Post by saagarjha »

titzer wrote: post #31
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…

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

Re: Memory access on the Apple M1 processor

#50

Post by wmf »

gameswithgo wrote: post #24
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.

Tiger Lake laptops such as the XPS 13.
Post reply on HN