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

151–160 of 278 posts

Re: Memory access on the Apple M1 processor

#151

Post by coldtea »

danaris wrote: post #107
marrvelous wrote: post #99

Earlier quoted context omitted.

With the walled garden, Apple can set enforceable timelines for the software ecosystem to adopt to architectural changes. Remember the transition to arm64? Apple forced everything on the App Store to ship universal binaries. Without the App Store walled garden, software isn’t required to keep up to date with architectural changes. Instead, keeping current is only a requirement to being featured on the App Store (whic…

Well, and on the Mac, it's not the only method. The walled garden here has big open gates. That said, all software on the Mac, post-Catalina, has to be 64-bit, whether it's distributed through the Mac App Store or not, because the 32-bit system libraries are no longer included at all.

>Well, and on the Mac, it's not the only method. The walled garden here has big open gates.

Gates are not incompatible with walled gardens. Most walled gardens have those.

Plus, I mentioned the walled garden as a good thing. It's part of the Apple proposition (even if not alll get it), and part of what it enables it to move at the speed it does (whether in the right or wrong direction).

But one can susbstitute "walled garden" with "tight control of the OS, hardware and imposed requirements on most of third party software, and willingness to enforce hard schedules (e.g. regarding removing 32-bit, OpenGL, etc) to all (or tons) of its developers at once.

Re: Memory access on the Apple M1 processor

#152

Post by anfilt »

anfilt wrote: post #111
coldtea wrote: post #91

Earlier quoted context omitted.

> Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What enabled/led them to make those choices where others haven't? The things people give them complains about: (a) keeping a walled garden, (b) moving fast and taking the platform to new directions all at once (c) controlling the whole stack Which means they're not beholden to compatibility with third party frameworks and big…

I will be honest as long apple keeps this walled garden shenanigans going. I am not buying any of their hardware.

What's with downvotes? I know some people don't mind, but it's a deal breaker to me, and it something I don't want to support.

I don't care how good their hardware is. Moreover, good luck sourcing parts if the device has trouble. Apple will not sell you the parts. Even if you wanted.

A walled garden does not make their hardware any better. If anything it makes it worse. I hope for Mac users apply does not clamp down further on Macs.

Re: Memory access on the Apple M1 processor

#153

Post by sliken »

jeffbee wrote: post #69
gameswithgo wrote: post #24

Earlier quoted context omitted.

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.

As WMF mentions, Tiger Lake laptops like my Razer Book have the same memory. It is not appreciably closer to the CPU in the Apple design. In Intel's Tiger Lake reference designs the memory is also in two chips that are mounted right next to the CPU.

Mind running a memory latency benchmark on your Razer Book? Does it run linux by chance?

Re: Memory access on the Apple M1 processor

#154

Post by ogre_codes »

danaris wrote: post #107
marrvelous wrote: post #99

Earlier quoted context omitted.

With the walled garden, Apple can set enforceable timelines for the software ecosystem to adopt to architectural changes. Remember the transition to arm64? Apple forced everything on the App Store to ship universal binaries. Without the App Store walled garden, software isn’t required to keep up to date with architectural changes. Instead, keeping current is only a requirement to being featured on the App Store (whic…

Well, and on the Mac, it's not the only method. The walled garden here has big open gates. That said, all software on the Mac, post-Catalina, has to be 64-bit, whether it's distributed through the Mac App Store or not, because the 32-bit system libraries are no longer included at all.

They are little tiny 6" tall walls that you can step over. Like micro-walls. Except for the bits where you have no walls at all. Like if you install literally any programming language, HomeBrew, or MacPorts.

The walls in the walled garden only exist in the heads of people who never use a Mac.

Re: Memory access on the Apple M1 processor

#155

Post by alblue »

kzrdude wrote: post #121
duskwuff wrote: post #32

Earlier quoted context omitted.

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

To be clear here, it fetches two cache lines but it doesn’t put the second in exclusive state until it’s written to; the unit of granularity is still 64b. In a scanning read mode you will see the benefit but you won’t see the contention on writes. (The contention will come from subsequent reads on that cache line though)

Re: Memory access on the Apple M1 processor

#156

Post by titzer »

alecco wrote: post #150
titzer wrote: post #123

Earlier quoted context omitted.

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.

Can you give an example? I've seen Lemire correct his posts on many occasions and the source code is published. I don't know many blogs doing anything remotely like that.

Sure. He often benchmark some small C++ code on his "laptop" CPU (which one exactly? microarchs matter!) and then committing classic microbenchmarking pitfalls such as:

- benchmarking something small enough to inspect machine code, but not inspecting machine code

- not plotting distribution, average, variance etc

- no attention paid to CPU frequency governor settings

- measuring too short a run

- measuring too small a dataset that it fits entirely in L1

Re: Memory access on the Apple M1 processor

#157

Post by valuearb »

adam_arthur wrote: post #94
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…

Certainly Apple's processors are far ahead, but they're a full process generation (5nm) ahead of their competitors. They paid their way to that exclusive right through TSMC. I'm sure they'll still come out ahead in benchmarks, but the numbers will be much closer once AMD moves to 5nm. You absolutely cannot fairly compare chips from different fab generations. I don't see many comments hammering this point home enough.…

A node shrink is going to help AMD by 15% at best, they are much farther behind than that on performance per watt.

AMD has done mobile CPUs that look as if they are close to or even ahead of the M1 in performance, but they all use 2x to 4x as much power. When higher core count versions of Apple Silicon are available, they will be able to have double the core counts of AMD chips at the same power levels.

And each those cores are significantly faster than individual AMD cores.

Re: Memory access on the Apple M1 processor

#158

Post by alblue »

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 also a lot bigger and has the advantage that as a fixed size isa can be much wider in execution than in x86 but that’s unlikely to be of benefit here, other than perhaps slightly in terms of queuing up multiple outstanding loads.

Re: Memory access on the Apple M1 processor

#159

Post by paulryanrogers »

jeffbee wrote: post #114
coldtea wrote: post #91

Earlier quoted context omitted.

> Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What enabled/led them to make those choices where others haven't? The things people give them complains about: (a) keeping a walled garden, (b) moving fast and taking the platform to new directions all at once (c) controlling the whole stack Which means they're not beholden to compatibility with third party frameworks and big…

Neither A nor C makes any sense, are not supported by evidence. There is no aspect of the mac or macOS that can be realistically described as a "walled garden". It comes with a compiler toolchain and ... well, some docs. It natively runs software compiled for a foreign architecture. You can do whatever you want with it. It's pretty open. A "walled garden" is when there is a single source of software.

Running apps downloaded outside the store requires jumping through an increasing number of hoops or vendors pay to get every build signed off by a single party.

Re: Memory access on the Apple M1 processor

#160

Post by coldtea »

anfilt wrote: post #152
anfilt wrote: post #111

Earlier quoted context omitted.

I will be honest as long apple keeps this walled garden shenanigans going. I am not buying any of their hardware.

What's with downvotes? I know some people don't mind, but it's a deal breaker to me, and it something I don't want to support. I don't care how good their hardware is. Moreover, good luck sourcing parts if the device has trouble. Apple will not sell you the parts. Even if you wanted. A walled garden does not make their hardware any better. If anything it makes it worse. I hope for Mac users apply does not clamp down…

>What's with downvotes?

Didn't downvote, but I think it's the same as when people read a "letter to the editor" of yore, declaring that some person "cancelled their subscription" because of something in the magazine.

A natural response is "Don't let the door hit you on your way out", which on HN might be expressed through a downvote by some.

>I don't care how good their hardware is. Moreover, good luck sourcing parts if the device has trouble. Apple will not sell you the parts. Even if you wanted.

Well, they repair all kinds of parts, and have guarantees and guarantee extension programs. But in any case, their allure was never "can find parts to build my own / repair damages forever" or in their stuff being cheap to own or fix/replace.

>A walled garden does not make their hardware any better.

Well, it does in a few ways. Mandating how the software is made, and what software is sold, when it should adapt new libs to continue being sold, etc, means that they can move the platform in different ways faster.

Post reply on HN