Memory access on the Apple M1 processor • Hacker News Board

Re: Memory access on the Apple M1 processor

#211

Post by sitkack » Thu, Jan 07, 2021, 5:10 AM UTC

jandrese wrote: post #101

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

It seems like Apple listened when people talked about how all modern processors bottleneck on memory access and decided to focus heavily on getting those numbers better. Of course this leads to the question that if everyone in the industry knew this was the issue why weren't Intel and AMD pushing harder on it? They already both moved the memory controller onboard so they had the opportunity to aggressively optimize i…

Because they both use new memory standards to force a refresh in their CPU platforms to cause more churn and revenue.

Re: Memory access on the Apple M1 processor

#212

Post by square_usual » Thu, Jan 07, 2021, 5:14 AM UTC

SurfingInVR wrote: post #125

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

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

It's $699, for a complete device, not a part of one.

Re: Memory access on the Apple M1 processor

#213

Post by astrange » Thu, Jan 07, 2021, 5:16 AM UTC

coldtea wrote: post #201

fartcannon wrote: post #194

Earlier quoted context omitted.

It's the same cowardly leadership that stewards both iOS and OSX. Ask Amphetamine about how open they are.

> Ask Amphetamine about how open they are. That's neither here nor there. (a) Amphetamine could still be sold outside the Mac App Store. (b) An app name could be problematic even in FOSS land. It's just that instead of Amphetamine being the name that causes it, it will be something else. E.g. with the trend of banning/changing terms like "master" (as in replication primary master, not as in the owner of slaves), unfo…

There are a lot of juvenile named open source projects that will definitely get in trouble or already have. GIMP and LAME are examples.

Re: Memory access on the Apple M1 processor

#214

Post by kristianp » Thu, Jan 07, 2021, 5:20 AM UTC

alblue wrote: post #158

kergonath wrote: post #4

It’s a good introduction, but it’s a bit disappointing that it ends that way. I’d love to read more about what’s behind the figure and more technical info about how it might work.

This isn’t specific to the M1 but I tap about cache lines in my last QCon presentation (where I also suggested that a 128b cache line wasn’t far away): https://www.infoq.com/presentations/microarchitecture-modern... However the speed benefits come from a much larger L1 cache and the fact that the ram is in the same chip which will reduce latency that is the benefit for most of it. The program (instruction) cache is a…

This post says that the m1 has a 128 byte cache line size. So that time has arrived!

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

Re: Memory access on the Apple M1 processor

#215

Post by epistasis » Thu, Jan 07, 2021, 5:22 AM UTC

sliken wrote: post #137

tandr wrote: post #117

Earlier quoted context omitted.

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

Here's the M1: https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... Scroll down to the latency vs size map and look at the R per RV prange. That gets you 30ns or so. Similar for AMD's latest/greatest the Ryzen 9 5950X: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di... The same R per RV prange is in the 60ns range.

Could this be coming from the page size being 4x as large for Apple Silicon versus x86? I don't fully understand the benchmark, but it appears to be accessing a variety of pages from the same first level TLB lookup?

It's been a long time since I dealt with this stuff (wanted to get 1GB huge pages in Linux for some huge huge hash tables), so maybe I'm misunderstanding.

Re: Memory access on the Apple M1 processor

#216

Post by wmf » Thu, Jan 07, 2021, 5:28 AM UTC

jack_pp wrote: post #206

adam_arthur wrote: post #97

Earlier quoted context omitted.

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

People keep pointing this out but has Intel had such significant performance improvements since sandy bridge? With x86 it seems that lately you would be foolish to upgrade less than once every 3-4 years because the difference is just not that significant

Over the last decade or so Apple has gone from 10x slower than Intel to parity, mostly by implementing techniques that were already known. Surpassing the state of the art may be harder to do consistently.

Re: Memory access on the Apple M1 processor

#217

Post by astrange » Thu, Jan 07, 2021, 5:28 AM UTC

acdha wrote: post #39

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

> What enabled/led them to make those choices where others haven't? Others have to some extent — AMD is certainly not out of the game — so I'd treat this more as the question of how they've been able to go more aggressively down that path. One of the really obvious answers is that they control the whole stack — not just the hardware and OS but also the compilers and high-level frameworks used in many demanding contex…

Intel does lots of contributions across the OS (Linux and glibc) to compilers including their own (gcc, icc, ispc, etc). Their problems aren't their ability, it's that Intel is poorly managed and internal groups are constantly fighting with each other.

Also, compiler support for CPUs is very overrated. Heavy compiler investment was attempted with Itanium and debunked; giant OoO CPUs like Intel's or M1 barely care about code quality, and the compilers have very little tuning for individual models.

Re: Memory access on the Apple M1 processor

#218

Post by philistine » Thu, Jan 07, 2021, 5:34 AM UTC

epistasis wrote: post #205

proverbialbunny wrote: post #145

Earlier quoted context omitted.

As a data scientist, I feel this. Intel and AMD don't own an OS or an app store, and you might be surprised how hard it is to get good data. Data is the new gold. If a company that can corner a piece of the market, they can collect data no one else can, and from that companies are often forced to partner or they can't properly provide services that will keep them competitive.

This makes me think that any sort of data advantage Apple may have has nothing to do with them owning an OS. Intel has a massive computer network, managed by their own IT team, just like any other large corporation. Intel could collect whatever performance data they want from actual users of actual programs just as easily as Apple could.

Apple is the only large company with a functional organization. Could that be it ? Coupled with their unparalleled ownership of a family of platforms (intel’s OS comparably is nonexistent).

Re: Memory access on the Apple M1 processor

#219

Post by wmf » Thu, Jan 07, 2021, 5:40 AM UTC

jandrese wrote: post #101

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

It seems like Apple listened when people talked about how all modern processors bottleneck on memory access and decided to focus heavily on getting those numbers better. Of course this leads to the question that if everyone in the industry knew this was the issue why weren't Intel and AMD pushing harder on it? They already both moved the memory controller onboard so they had the opportunity to aggressively optimize i…

The Apple, Intel, and AMD memory controllers all look pretty similar in performance to me. Memory latency is the same at ~100 ns; Firestorm is clocked lower so latency is lower in terms of cycles. One Firestorm core can saturate the memory controller while Intel/AMD can't so that should be an advantage for single-threaded scenarios. Intel/AMD are behind, but I wouldn't say embarrassingly so and they haven't been lazy.

Re: Memory access on the Apple M1 processor

#220

Post by wrsh07 » Thu, Jan 07, 2021, 5:42 AM UTC

jayd16 wrote: post #105

wrsh07 wrote: post #51

Earlier quoted context omitted.

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

I think 5% is a non-trivial difference but alright, its a much bigger difference on the M1. I guess I still don't understand whats going on here. Scenario 1 has two spatially close reads followed by two dependent random access reads. Scenario 3 (2+) has two spatially close reads, and two pairs of dependent random access reads of two spatially close locations. Why does it follow that this is caused by a change in memo…

I think the 5% can maybe be accounted for by the cache line (you mentioned this above, and I don't think the experiment does anything to prevent the issue)? If it's 1/16th chance of crossing the cache line, that maybe is about 5% of the time? I say that with pretty low confidence though

I think you raise a good question, though -- what really is going on here? Is this just a missed optimization compiling for the m1?

Or is it actually something fundamental about how reads happen with an m1? I'm definitely not knowledgeable enough to know how to answer this