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

121–130 of 278 posts

Re: Memory access on the Apple M1 processor

#121

Post by kzrdude »

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.

(As I learned from recent Rust concurrency changes) on newer Intel, it usually fetches two cache lines so effectively 128 bytes while AMD usually 64 bytes. That's the sizes they use for "cache line padded" values (I.e making sure to separate two atomics by the fetch size to avoid threads invalidating the cache back and forth too much).

Re: Memory access on the Apple M1 processor

#122

Post by foldr »

jeffbee wrote: post #115
foldr wrote: post #102

Earlier quoted context omitted.

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

You can't just eyeball the PCB layout for a GHz frequency circuit and say "yeah that would definitely work just the same if you moved that component 2mm in this direction". It's certainly possible to use longer trace lengths, but that may come with tradeoffs.

>The only thing you can say against them is they might consume more power driving that trace

Power consumption is really important in a laptop, and Apple clearly care deeply about minimising it.

For all we know for sure, moving the memory closer to the CPU may have been part of what's enabled Apple to run higher frequency memory with acceptable (to them) power draw.

Re: Memory access on the Apple M1 processor

#123

Post by titzer »

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…

Frankly, I find Lemire does oversimplified, poor-quality control, back-of-the-envelope microbenchmarking all the time that provides little to no insight other than establishing a general trend. It's sophomoric and a poor demonstration about how to well-controlled benchmarking that might yield useful, repeatable, and transferrable results.

Re: Memory access on the Apple M1 processor

#124

Post by reasonabl_human »

sliken wrote: post #89
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…

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.

Mind sharing the micro benchmark you wrote? I’m curious to know how that would work

Re: Memory access on the Apple M1 processor

#125

Post by SurfingInVR »

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…

Something I've seen no one else mentioning: Apple's low-spec tier is $1000, not $70.

Re: Memory access on the Apple M1 processor

#126

Post by acdha »

qeternity wrote: post #52
wmf wrote: post #22

Earlier quoted context omitted.

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

I think this is part of the reason where there are so many people trying to find reasons to downplay it: humans love the idea of “one weird trick” which makes a huge difference and we sometimes find those in tech but rarely for mature fields like CPU design. For many people, this is unsatisfying like asking an athlete their secret, and getting a response like “eat well, train a lot, don't give up” with nary a shortcut in sight.

Re: Memory access on the Apple M1 processor

#127

Post by ChuckNorris89 »

dcolkitt wrote: post #106
jeffbee wrote: 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 doesn't need to acquire Intel, they need to do what Apple did and acquire a stellar ARM design house that will build a chip with x86 translation, tailored to accelerate the typical workloads on Windows machines and sell those chips to the likes of Dell and Lenovo and tell developers "ARM Windows is the future, x86 Windows will be sunset in 5 years and no longer supported by us, start porting your apps ASAP and in the mean time, try our X86 emulator on our ARM silicon, it works great."

Microsoft proved with the XBOX and Surface series they can make good hardware if they want, now they need to move to chip design.

Re: Memory access on the Apple M1 processor

#128

Post by acdha »

syntaxing wrote: post #88

I’m super curious if it’s true that my 8GB M1 will die quickly because of the aggressive swaps. I guess time will tell.

FWIW, I have a 2010 MBA which was _heavily_ used for years as a primary development system. The SSD only started to show signs of degraded performance last year and that wasn't massive. I would be quite surprised if the technology has become worse.

Re: Memory access on the Apple M1 processor

#129

Post by gigatexal »

f6v wrote: post #118
dcolkitt wrote: post #106

Earlier quoted context omitted.

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?

Nope. Not a lawyer but I doubt it at all.

Re: Memory access on the Apple M1 processor

#130

Post by dv_dt »

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…

No fighting the sales department on where to put the market segmentation bottlenecks?
Post reply on HN