Live data from Hacker News

Memory access on the Apple M1 processor

lemire.me

181–190 of 278 posts

Re: Memory access on the Apple M1 processor

#181
post #69

Earlier quoted context omitted.

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.

And (genuine question) how do the Tiger Lake laptops compare with the M1 MacBooks thus far?

The raw CPU performance of the M1 is about 15% faster single core, and 50% faster multicore, while using nearly half as much power.

Re: Memory access on the Apple M1 processor

#182
post #175

Earlier quoted context omitted.

My guess is it had to do with limitations tied to the x86_64 instruction set. It doesn't matter how much modifications you do, if you don't start with a good foundation, you're going to be limited to that foundation.

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 as narrow as current x86 cores.

Re: Memory access on the Apple M1 processor

#183
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…

>that it's "on-die" (it's not)

It appears to be mounted on the same chip package.

Why did Apple do this if not for speed?

Re: Memory access on the Apple M1 processor

#184
post #175

Earlier quoted context omitted.

My guess is it had to do with limitations tied to the x86_64 instruction set. It doesn't matter how much modifications you do, if you don't start with a good foundation, you're going to be limited to that foundation.

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.

Re: Memory access on the Apple M1 processor

#185

Earlier quoted context omitted.

You don't have to pay to have your apps signed off (notarized).

I'll have to check again because if that's the case it's still a walled garden, just with free admission.

Just right-click > Open and you can do anything you want.

Re: Memory access on the Apple M1 processor

#186

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.

32-bit Windows software is actually supported through WINE and works in Rosetta.

Re: Memory access on the Apple M1 processor

#187
post #141
post #110

Earlier quoted context omitted.

You _need_ to use -mnative because it otherwise retains backwards compatibility to older x86.

(base) Coding % cc -mnative two-three.c clang: error: unknown argument: '-mnative' (base) Coding % cc -v Apple clang version 12.0.0 (clang-1200.0.32.28) Target: x86_64-apple-darwin20.2.0 Thread model: posix

It's spelled "-march=native" in gcc and "-arch x86_64h" in clang.

It doesn't make much difference though, autovectorization doesn't work very well and there is not a lot of special optimization for newer x86 CPUs.

Re: Memory access on the Apple M1 processor

#188

Earlier quoted context omitted.

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.

"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

Re: Memory access on the Apple M1 processor

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

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 clocked at 30% to 50% less of the x68 designs, especially in FP operations. The alternative designs explored and utilised wider and deeper pipelines, bigger L1 caches and various optimisations across the entire CPU arch. Every alternative CPU design had something unique to offer, and that was a great thing to read about and study.

The commoditisation of the PC hardware has driven great CPU designs into an extinction. Heck, even Oracle, that are now in the business of litigation for fun and a massive profit, with its prodigious cash war chest has discontinued the UltraSPARC architecture due to it requiring extraordinary investments on multiple fronts. PC users have long been forced to be content with whatever bone the CPU architecture coloniser would throw at them. There appears to be a resurgence of the great engineering with M1, and, hopefully, that will lead to more of the thoughtful engineering in medium to long term.

M1 is fast due to: a solid, single vision of what a modern CPU should be like, continuous investment into R&D over an extended period of time, a well concerted effort of the engineering, design ideas reuse across multiple product lines, supply chain management, and, of course, the manufacturing process. Nanometers do not make for a great CPU design but rather play a supporting role. If the nanometers were so important, the 2017 POWER9 design manufactured at a 14 nm process with a smaller L1 cache would not have been able to outperform any existing x86 design in 2020 in both, single core and multi core (with 25% to 50% lesser number of physical cores) setups? Ryzen 3 has narrowed the gap, but POWER9 still takes the lead and POWER10 is around the corner.

There is a great quote by Michael Mahon, a principal HP architect, in the foreword to the PA RISC 2.0 CPU architecture handbook from 1995:

The purpose of a processor architecture is to define a stable interface which can efficiently couple multiple generations of software investment to successive generations of hardware technology. Stability and efficiency are the goals, and the range of software and hardware technologies expected during the architecture’s life determine the scope for which the goals must be achieved

...

Efficiency also has evident value to users, but there is no simple recipe for achieving it. Optimizing architectural efficiency is a complex search in a multidimensional space, involving disciplines ranging from device physics and circuit design at the lower levels of abstraction, to compiler optimizations and application structure at the upper levels.

Because of the inherent complexity of the problem, the design of processor architecture is an iterative, heuristic process which depends upon methodical comparison of alternatives («hill climbing») and upon creative flashes of insight («peak jumping»), guided by engineering judgement and good taste.

To design an efficient processor architecture, then, one needs excellent tools and measurements for accurate comparisons when «hill climbing,» and the most creative and experienced designers for superior «peak jumping.» At HP, this need is met within a cross-functional team of about twenty designers, each with depth in one or more technologies, all guided by a broad vision of the system as a whole.

Well executed holistic approach is the reason why the entry level M1 is fast. We need more of «holistic-ism» in engineering everywhere.

Re: Memory access on the Apple M1 processor

#190

Earlier quoted context omitted.

The outcome seems to depend greatly on the physical design of the laptops. The elsewhere-mentioned Dell XPS 13 has a particularly poor cooling design, which is why I chose the Razer Book instead. Despite being marketed in a very silly way to gamers only, it seems to have competent mechanical design.

Gamers are likely to run their systems with demanding workloads, for hours, with a color-coded performance counter (FPS stat). They'll notice if it throttles. They're particularly demanding customers, and there's quite a bit of competition for their money.

How common are laptops for gamers? I always build my windows boxes but I’m a casual gamer.
Post reply on HN