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?
Memory access on the Apple M1 processor
181–190 of 278 posts
Re: Memory access on the Apple M1 processor
#182Earlier 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…
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
#183Great 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…
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
#184Earlier 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…
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
#185Re: Memory access on the Apple M1 processor
#186Earlier 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.
Re: Memory access on the Apple M1 processor
#187Earlier 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 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
#188Earlier 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…
Re: Memory access on the Apple M1 processor
#189Earlier 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 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
#190Earlier 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.