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

191–200 of 278 posts

Re: Memory access on the Apple M1 processor

#191

Post by nkurz »

astrange wrote: post #184
nkurz wrote: post #175

Earlier quoted context omitted.

I think the current consensus among experts is that the instruction set is not the limiting factor. Modern x64 microprocessors have a separate front-end that handles instruction decoding. These instructions are decoded to internal proprietary "micro-ops". The internal buffers and actual execution units see only these µops. One can measure where the bottlenecks are, and it's rare to find that the front-end is the bott…

There are real differences in processors caused by their ISAs - it's not true that decoders mean it's all the same RISC in the backend. For instance, it's hard to combine instructions together, which is actually an advantage for x86 (the complex memory operands come for free). But it also guarantees memory ordering that ARM doesn't which is a drawback. I'm not sure how important this is in practice.

> For instance, it's hard to combine instructions together, which is actually an advantage for x86 (the complex memory operands come for free).

True, although I just looked at the ARM assembly for Daniel's example, and it's making good use of "ldpsw" to load two registers from consecutive memory with a single instruction. So in this particular case, it may be a wash.

> But it also guarantees memory ordering that ARM doesn't which is a drawback.

Yes, I wasn't considering the memory model to be part of the instruction set. I agree that in general this could be a big difference in performance, although I don't think it comes up in Daniel's example.

I added a comment to Daniel's blog with my guess as to what's happening to cause the observed timings in his example. Feedback from anyone with better knowledge of M1 would be appreciated.

Re: Memory access on the Apple M1 processor

#192

Post by nkurz »

wtallis wrote: post #182
nkurz wrote: post #175

Earlier quoted context omitted.

I think the current consensus among experts is that the instruction set is not the limiting factor. Modern x64 microprocessors have a separate front-end that handles instruction decoding. These instructions are decoded to internal proprietary "micro-ops". The internal buffers and actual execution units see only these µops. One can measure where the bottlenecks are, and it's rare to find that the front-end is the bott…

> One can measure where the bottlenecks are, and it's rare to find that the front-end is the bottleneck. Part of this is due to the fact that x86 processor designers won't include more execution units than they can feed from their instruction decoders. Apple's processors are much wider than x86 on both the decode and execution resources, and it's pretty clear that the M1 would not perform as well if its decoders were…

> it's pretty clear that the M1 would not perform as well if its decoders were as narrow as current x86 cores

This would imply that it's able to sustain ILP greater than 4 (or maybe 5 with macro-fusion). Does it actually manage to do this often? If so, that's really impressive. I was guessing that most of the advantage was coming from the improved memory handling, and possibly a much bigger reorder buffer to better take advantage of this, but I'm happy to be shown otherwise.

Re: Memory access on the Apple M1 processor

#193

Post by kortilla »

martamorena2 wrote: post #135
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…

That's bizarre. As if CPU vendors were unable to run "realistic" workloads. If they truly aren't, that's because they are unwilling and then they are designing for failure and Apple can just eat their lunch.

It’s a big world out there. Workloads in data science vs gaming vs hft vs packet processing vs web servers are all extremely different.

Even if you know about them, you need an expert in each to truly push the hardware to the real limits that get hit in the respective industry. The small differences between real implementations and simulated loads can drastically alter the performance characteristics and cause proc manufacturers to miss the mark.

Re: Memory access on the Apple M1 processor

#194

Post by fartcannon »

ogre_codes wrote: post #148
fartcannon wrote: post #92

Earlier quoted context omitted.

They could still do all this shit without the walled garden. To me, it suggests they aren't willing to compete. They're anti-competitive.

> They could still do all this shit without the walled garden. They do. MacOS isn't a walled garden. > They're anti-competitive Have you heard of this little company from Washington called Microsoft? They have something like 85% of the PC market. There is another OS called Linux. About 85-90% of the internet runs on it. I can understand a little where people get the idea the iPhone is anti-competitive, but we're talk…

It's the same cowardly leadership that stewards both iOS and OSX.

Ask Amphetamine about how open they are.

Re: Memory access on the Apple M1 processor

#195

Post by sjwright »

ralfd wrote: post #138
ChuckNorris89 wrote: post #127

Earlier quoted context omitted.

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…

Apple has at most 10% of the computer market and is just one player among many. I am skeptical Microsoft with their 90% dominance would or should be allowed this much power over the industry.

The traditional personal computer market isn't nearly as important as it used to be. However you slice the pie, there's no way you can define the pieces to be 10% Apple and 90% Microsoft with a straight face.

Re: Memory access on the Apple M1 processor

#196

Post by ogre_codes »

fartcannon wrote: post #194
ogre_codes wrote: post #148

Earlier quoted context omitted.

> They could still do all this shit without the walled garden. They do. MacOS isn't a walled garden. > They're anti-competitive Have you heard of this little company from Washington called Microsoft? They have something like 85% of the PC market. There is another OS called Linux. About 85-90% of the internet runs on it. I can understand a little where people get the idea the iPhone is anti-competitive, but we're talk…

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

I do wish people would keep the quasi-religious aspects out of things.

Amphetamine is a perfect example of how the Mac isn't a walled garden. They always had the option top sell outside the App Store. That is fundamentally the difference between what makes a platform a walled garden. They might have lost some sales because they couldn't participate in the Mac App Store, but they could still sell their product. Some companies choose to avoid the Mac App Store because they don't like Apple's policies.

Re: Memory access on the Apple M1 processor

#197

Post by adam_arthur »

valuearb wrote: post #172
GeekyBear wrote: post #164

Earlier quoted context omitted.

AMD's mobile chips are still on Zen 2 cores, so they are behind the M1 on single core performance in both integer and floating point. It's their desktop chips running Zen 3 cores that trade blows on single core integer math, depending on which benchmark you look at. https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... Of course, on multi-core performance you can buy a desktop chip with a much higher Zen 3…

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. https://cpu.userbenchmark.com/Compare/Intel-Core-i9-10900K-v...

Re: Memory access on the Apple M1 processor

#198

Post by coldtea »

mamp wrote: post #188
matthew-wegner wrote: post #177

Earlier quoted context omitted.

"A" does matter a bit. Builds are uploaded to the App Store include bitcode, which Apple strips on distribution. According to docs, enabling bitcode: "Includes bitcode which allows the App Store to compile your app optimized for the target devices and operating system versions, and may recompile it later to take advantage of specific hardware, software, or compiler changes." It seems quite likely they have (and proba…

Most non-Apple apps aren’t from the App Store

Doesn't matter for the purposes of what the parent mentioned.

It's enough that enough of them are.

Plus, even if most aren't, the "short tail" people use these days probably are.

Re: Memory access on the Apple M1 processor

#199

Post by smoldesu »

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…

The big "enabler" was their mass-purchase of 5nm lithography across the board. Even still though, 4ghz*8c isn't anything new, and isn't really that remarkable besides the low TDP (which is incidentally dwarfed by the display, which draws up to 5x more power than the CPU does). I think the big issue is that Apple has painted themselves into a corner here: ARM won't play nice with the larger CPUs they want to make, and the pressure for them to provide a competent graphics solution on custom silicon is mounting. They spent a lot of time this generation marketing their "energy efficiency" and battery life, but many consumers/professionals (myself included) don't really care about either of these things.

Re: Memory access on the Apple M1 processor

#200

Post by [deleted] »

inkyoto wrote: post #189
adam_arthur wrote: post #94

Earlier quoted context omitted.

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

The 5nm vs 7nm vs 10nm vs whatever nm narrative is highly reminiscent that of clock rate flame wars raging in the tech bubble over a decade ago. Back in the early aughts, when the great engineering was still a thing, alternative CPU designs (DEC Alpha 21264, MIPS 10k/12k, PA RISC, POWER and later UltraSPARC designs) were consistently outperforming any x86 design by at least an order of magnitude or more whilst being…

[deleted]
Post reply on HN