Memory access on the Apple M1 processor • Hacker News Board

Re: Memory access on the Apple M1 processor

#271

Post by valuearb » Fri, Jan 08, 2021, 10:23 PM UTC

adam_arthur wrote: post #197

valuearb wrote: post #172

Earlier quoted context omitted.

The Ryzen 5950x has 135 watt TDP in actual use. That’s roughly 8x the M1. https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di... And Ryzen chips are offered with more cores, but that’s an extremely temporary advantage (reminds me of the friend who told me not to buy Apple stock because they didn’t have big screen phones). When Apple fits 32 Firestorm cores in a 135 watt TDP package, AMD isn’t going to have a…

Power consumption is not linear as it relates to performance. CPUs designed for the desktop are going to use excessive power by design. They'll often use many times more power than mobile equivalent, but only have slightly better single core performance. Here's a great example, Intel Core i9 (Desktop, 125w TDP) vs Intel Core i7 (Laptop, 15W). Huge power difference, only ~10% difference in single core clock speeds. ht…

It might not be linear in terms of single core performance, where Apple already dominates, but it sure has a nearly linear relationship to multicore performance.

Re: Memory access on the Apple M1 processor

#272

Post by adam_arthur » Fri, Jan 08, 2021, 10:46 PM UTC

valuearb wrote: post #271

adam_arthur wrote: post #197

Earlier quoted context omitted.

Power consumption is not linear as it relates to performance. CPUs designed for the desktop are going to use excessive power by design. They'll often use many times more power than mobile equivalent, but only have slightly better single core performance. Here's a great example, Intel Core i9 (Desktop, 125w TDP) vs Intel Core i7 (Laptop, 15W). Huge power difference, only ~10% difference in single core clock speeds. ht…

It might not be linear in terms of single core performance, where Apple already dominates, but it sure has a nearly linear relationship to multicore performance.

Ok, but their multicore score is only on par, not better than equivalent class chips on older fab generations. Where is the huge gap?

https://wccftech.com/intel-and-amd-x86-mobility-cpus-destroy...

Or check multicore scores here: https://browser.geekbench.com/mac-benchmarks

m1 is better by 20% or so, but is 2 fab generations ahead of the intel chips

Re: Memory access on the Apple M1 processor

#273

Post by andrei-at » Sat, Jan 09, 2021, 4:03 PM 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.

Hi, Andrei here.

Just a clarification as to why the P per RV prange numbers are good: This pattern is simply aggressively prefetched by the region prefetcher in the M1, while Zen3 doesn't pull things in as aggressively.

Re: Memory access on the Apple M1 processor

#274

Post by valuearb » Sun, Jan 10, 2021, 2:50 AM UTC

adam_arthur wrote: post #272

valuearb wrote: post #271

Earlier quoted context omitted.

It might not be linear in terms of single core performance, where Apple already dominates, but it sure has a nearly linear relationship to multicore performance.

Ok, but their multicore score is only on par, not better than equivalent class chips on older fab generations. Where is the huge gap? https://wccftech.com/intel-and-amd-x86-mobility-cpus-destroy... Or check multicore scores here: https://browser.geekbench.com/mac-benchmarks m1 is better by 20% or so, but is 2 fab generations ahead of the intel chips

The M1 only has 4 Firestorm cores and 15 watts TDP. It’s other four cores are Icestorm cores offering roughly 1/10th the performance and 1/3rd the power draw.

https://www.anandtech.com/show/16192/the-iphone-12-review/2

The Ryzen 4900H is a 55 watt TDP part with eight performance cores. Despite that it’s far behind the M1 in GeekBench single core and multicore scores.

https://browser.geekbench.com/v5/cpu/search?q=4900H

Now as you shown it’s way ahead in Cinebench 23 Multicore benchmark. Let’s assume that’s more representative of real world use, and that being a process behind it will add 15% higher performance when AMD makes a 5 nm successor. That would increase its Cinebench Multicore to roughly 12,700, roughly 60% higher than the M1.

But all Apple has to do is come out with an M1X with eight Firestorm cores. That’s a multicore performance in the same range as the best possible 5 nm AMD CPU, and a TDP barely half of the AMD CPU. And far higher Cinebench single core, and GeekBench single/multicore ratings.

Obviously to swap Firestorm for IceStorm cores they need more transistors or something else has to go (on chip GPU?).

And Apple won’t be making 20 hour MacBook Airs out of this M1X, but they will be able to make 14 hour MacBook Pros with faster discrete GPUs.

And they are about 6 months from doing exactly that. Which is likely going to before AMD 5 nm, so top of line 4900H laptops get smoked on all Cinebench and GeekBench scores while using nearly double the power.

Re: Memory access on the Apple M1 processor

#275

Post by bradknowles » Sun, Jan 10, 2021, 3:27 AM UTC

jeffbee wrote: post #79

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…

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…

There’s another factor here, that I learned when I did a six month contract at Apple Retail Software Engineering.

In short, Apple has a number of 10x engineers that they move around to whatever project needs the most help, whether that is hardware, or application software, or operating system software, or services infrastructure, or whatever.

If some project starts getting enough negative “above the fold” coverage, then they will be temporarily gifted one or more of these special engineers.

Do that enough times, and those 10x engineers will gain enough experience in enough different areas that they will be able to reason well about the other end of whatever pipeline they’re on, and will know other 10x engineers that they can work with on that other end of the pipeline, because they had previously worked with them on some other project in the past months or years.

And those 10x engineers really will make a huge difference in what that project is capable of delivering.

The key failure of this operating mode is that most of the 10x engineers never get enough time to transfer much knowledge or skills to the others on the temporary team they are currently working with, and so things will start slowly deteriorating when they are necessarily moved on to the next project.

Rinse and repeat.

Re: Memory access on the Apple M1 processor

#276

Post by bradknowles » Sun, Jan 10, 2021, 3:34 AM UTC

icedchai wrote: post #261

mechEpleb wrote: post #241

Earlier quoted context omitted.

90% dominance of what is increasingly a small niche market. Apple controls a large fraction of the mobile device market, and everything else runs linux.

The fact is outside of the tech scene, most businesses and consumers runs Windows. To say this is a "small niche market" is laughable. Microsoft is everywhere.

Compare how many millions of desktop PCs there are in the world, versus the billions of mobile devices.

Re: Memory access on the Apple M1 processor

#277

Post by kergonath » Sun, Jan 10, 2021, 11:37 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…

Thanks!

Re: Memory access on the Apple M1 processor

#278

Post by lilyball » Sun, Jan 10, 2021, 8:15 PM UTC

vlovich123 wrote: post #176

lilyball wrote: post #163

Earlier quoted context omitted.

Do you have any insight as to why libdispatch added support for this new clock internally (in the last year or two), but did not expose it in any public API? In C I can manually construct a dispatch_time_t that will use make libdispatch use CLOCK_MONOTONIC_RAW¹, if I'm willing to make assumptions about the format of dispatch_time_t² (despite libdispatch warning that the internal format is subject to change³). And I c…

I haven't worked at Apple in almost 5 years so I can't speak to more recent developments unfortunately. libdispatch integration may be trickier & have implementation details not suitable for a public API. Specifically if I recall correctly the internal representation of time only allowed for 2 formats (wallclock vs monotonic). I suspect adding other types of clocks could pose back/forward compat challenges. However,…

The way dispatch_time_t currently works, having the high bit (bit 63) 0 means based on uptime (or mach_absolute_time()), having bits 63 and 62 both set to 1 means based on the wall clock, and the addition here is having 63 set to 1 and 62 set to 0 means based on continuous time. I don’t think they have the room to add a 4th clock though.