Hacker News Reader

Comment by api | Hacker News Reader

Yeah seeing a MacBook Air beat an i9 is hilarious.

I think this should put arguments over X86 efficiency disadvantages to bed. The X86 is obviously a huge boat anchor. There is no other explanation for this monstrous of a performance efficiency gap... unless Apple has invented something fundamentally new that has never been done in the entire history of CPU design. I doubt that.

View on HN

I doubt the instruction set is the only (or even the main) advantage M1 has. Apple just has been hiring some of the best talent in the field for a long time now that have been working on their phone/tablet chips and now used their talents on the M1.

There is a lot you can do to improve a CPU without changing the instruction set or manufacturing process just by doing a better job at designing the CPU itself. (look at Ryzen 5000 series with 15 to 20% IPC gain over the 3000/4000 series while staying on the same manufacturing process for example)

Basically there is a lot to gain just by doing a better design on the CPU itself. Also faster CPUs/GPUs allows one to build faster CPUs/GPUs just because as with more compute around you can run simulations faster/with more accuracy thus allowing faster development/better designs.

Here's a really good article describing why the M1 chip is so fast. Tl;dr it's a beefy CPU with a massive reorder buffer, and a bunch of discrete subsystems (gpu, ml core, dsp, etc).

https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...

Not to mention that the M1 has a manufacturing node advantage (which can really help with perf-per-watt).

I think people should pay more attention to the LPDDR4X RAM that's tightly coupled to the CPU and likely has significantly less latency and more bandwidth than anything on the Ryzen or i9. This is critical to keeping their wide design fed, and if you swapped this out with standard DDR3200 you'd see some lackluster numbers.

Both Intel and AMD try to overcome the memory wall with larger caches and clever prefetching, which is going to chew up more die space and power than x86 decoders.

How would one benchmark memory performance (DRAM latency & bandwidth) on the various chips?

Above my pay grade! You probably operating with a fixed speed on M1 so you can't intentionally cripple it, but it would be interesting to see "What would this look like if Apple had paired it with standard DDR4-3200?". AMD's Zen core's are known to respond well to lower latency RAM, but in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package. You could try benchmarking the Intel and Ryzen chips with DDR4 5000 and try carefully tuning the memory frequency and timing to find the right balance of bandwidth and latency.

> in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package.

I mean, that's exactly how an 11th Gen Core laptop is constructed.

> but in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package.

You can run basically any Intel CPU at DDR4-4266 without any issue. Or you can go thread ripper and laugh in quad channel memory. Or Intel x299 and triple-channel memory.

You don't have to tune anything, either, the RAM comes pre-tuned with the right timings in the XMP profile.

DDR5 is coming to consumer platforms probably 2022

this is a reasonable test: https://www.cs.virginia.edu/stream/ref.html

but it's pretty straightforward to just copy giant buffers in order/out of order and squint really hard at the results

Anandtech measured the ram latency at >90ns, which is not great:

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

The cache on the M1 is also massive. If Intel/AMD have clever prefetchers to make up for this, it looks like the M1 might be doing something more.

I have been trying to explain to people that having the DRAM chips physically next to the SOC on the package does not actually meaningfully improve memory latency.

I get that people on this site are excited, but please be excited about the right things.

Yeah, speed of PCB transmission is ~8 inches (~20cm) per nanosecond. Which is about 2/3 of the classic "light-nanosecond", which is roughly a foot.

People seem to have dramatically missed the point here; it's almost certainly done for power reasons.

And also for silicon budget, probably: short distances require small interface transistors and thin wires compared to massive distances like 5cm.

The chip area can be re-used for compute-sized transistors and wires (much, much smaller than interface transistors and wires, so there can be many more of them).

Why would that RAM have less latency? Do you have any sort of a source for why you think that?

LPDDR4X-4266 memory and its right on the chip.

I'd really like to see what AMD could do with a huge die that combines 8 Zen 3 cores, 16 GB of LPDDR4X-4266, and their GPU all on a single chip.

I'm very excited about the performance that Apple has been able to generate with this silicon, but these tests don't put anything to bed.

You're giving up extreme choice and expandability for performance by going the M1 route. You can spend $1700 for a Mac Mini with 16 GB of RAM and a 2 TB SSD, but that's what you're stuck with. Forever. Until its time to buy a new computer. People who bought into AMD's AM4 platform at the start were able to go up from the 1000 series to the 3000 series, able to upgrade their RAM from nearly any size to 64 GB, and able to upgrade their SSDs by slotting in a new NVMe drive. To say nothing of the GPU, which for developers of specific solutions, is becoming a serious concern. Also if you game in your spare time, you're at a disadvantage not just due to the Apple ecosystem, but also limited by the GPU.

For most of us, our machines are disposable. Even though I still build myself a new workstation every 2-3 years, I never bother selling it, I just give it away to family because for me its not worth the hassle, and then I order $3-4000 in parts and build a new one all over again. So buying the new Mac Mini made sense for me, although I opted to go with the base model for $699 so I could evaluate it and determine if going "all-in" for a higher-end model made sense (it does), but not for one second am I under the illusion that this chip is going to be the death of x86.

Well, Apple has managed to move all the way down to a 5nm process while Intel still hasn't made it past 14nm. AFAIK that's the largest limiting factor for Intel. I can't speak to why they have been stuck there for so long.

I’m not sure about 5nm but I know they were targeting 7nm and something broke that set them back till 2022/23. Not looking good for intel

https://www.tomshardware.com/news/intel-announces-delay-to-7...

Leaving aside the fact that process size is a marketing term these days, I’m currently typing this on a previous-gen Macbook Air with a 10nm Intel CPU. They’re definitely not stuck on 14nm.

yes but GP is still correct in general if not in the specifics. Practically speaking they can fit way more transistors on the die which translates to more power for more types of things whether it's M1 or 888.

They are effectively stuck on 14nm. They are unable to produce 10nm chips at scale at an acceptable yield, and the power and performance characteristics are not as good as expected either.

There's a reason the only laptops getting 10nm are low-quantity premium laptops.

> Leaving aside the fact that process size is a marketing term these days

There was a youtube video where the guy used a scanning electron microscope to compare gate sizes between 14nm intel and 7nm AMD and both were basically the exact same size.

The conclusion was that the term is useful only to compare a single companies product line against other offerings in that line (eg comparing Intel's 14nm to Intel's 20nm makes sense but comparing Intel to AMD based on node size is meaningless).

I think you are speaking of der8auer and this video in particular: https://youtu.be/1kQUXpZpLXI?t=716

Yes! That’s the one, thanks. It was a very interesting video.

The i9 from the article is a 14nm "tweaked Skylake" part, i.e. the uarch has been on the market for ~five years.

> I can't speak to why they have been stuck there for so long.

Semiconductor manufacturer has been able to use refractive optics (lenses) for decades and decades. The biggest change until now was to immersion lithography as we started getting into UV. Now we're into EUV (extreme UV). Lenses no longer work, everything has to be done with reflective optics (and even then the mirrors get ablated over time). It's the biggest single change in lithography we've seen and Intel still hasn't been able to pull it off in volume.

I think process node is overrated here. If the only thing that Intel was struggling with was process nodes and the rest of their designs were amazing, Apple would have probably stayed with them and encouraged them to outsource their chip fab work.

Apple is getting performance that matches the best of Intel has while beating the power draw of basically all they have.

And it's not just the CPU. The built in GPU of the MBA is surprisingly powerful, and the neural engine is beyond what Intel has.

Yes, Intel needs to get their chip fab back on track, but I also think they have issues with their chip designs (and perhaps something larger with x86).

My intuition is that x86's wasted die space on instruction decoding, backwards compatibility, etc. can be spent on making bigger and wider cores, and this seems to be what M1 is doing.

However, there are still some other aspects to consider. One is Apple's process lead against both Intel and AMD. The next is the memory situation; it'll be interesting to see if increased latency from more conventional configurations will change the dynamics much. (I suspect no, but some people suspect yes.)

The x86 space for decoding is tiny. The inefficiencies have to come from elsewhere and at least partially from the node difference. An architecturally big one is that x86 only implements SeqCst for atomics whereas looser memory models can allow multi-process programs to be written more efficiently (which they have been already for mobile).

In other words I think the problem has to do with the semantics of x86 more than the syntax of decoding x86.

This was explored in detail in another thread, it seems most of the gains are from looser memory ordering.

By the way, does someone knows where RISC-V stands regarding this ?

I think that Apple "just" [1] picked a very happy place in the parameter space: lower clock means that main memory (which is already lower latency than usual) is "nearer" to the cpu plus a larger L1 with a shorter latency (3 cycles). These (plus probably a larger amount of sustainable outstanding misses) imply that the cpu stalls less which means that they can sustain a larger ILP [2]. A better branch predictor (which is rumored to be best in class, although I haven't seen any in depth analysis) means that they can usefully have a larger reorder buffer and extract even more ILP and memory level parallelism. Finally the large width can take advantage of the extracted parallelism.

The weaker memory model should help extracting additional memory level parallelism, but I doubt that ordering has large impact. M1 is quite good even when running in TSO mode.

[1] of course they need to be commended for this, they went against the usual wisdom, probably because their CPU was designed to be low power first then high performance, not the other way around.

[2] typically the average ILP for normal applications is 1.5 instructions per cycle, but the variance is high, so if you reduce the amount of cycles the cpu is stalled, the ILP can go up fast.

You’re right. Like I said, atomics are one space. Another as you point out is that the memory architecture is pretty unique at providing high throughout and lower latency than traditional x86 architectures. I suspect Intel and AMD will adjust their roadmaps accordingly as a result of this new competition.

Where does the low-latency claim come from? Benchmarks do not validate it, giving main memory latency of around 100 ns.

Apparently you are right, but because of the lower clock, main memory is still closer in cycles. It would also be interesting to know the amount of outstanding main memory references.

I agree with the rest, but memory latency is actually pretty poor on the M1:

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

Yes I agree, it's more the semantics and the legacy of x86 (page sizes, MMU, memory models - even though Rosetta still runs faster than x86) than simply decoding.

It’s not the instruction decoder that wastes die space. In fact, it’s less than 5% of the die (on Skylake).[0]

[0]: https://pbs.twimg.com/media/EXFJLebXkAYkXTr?format=jpg&name=...

In case that link dies, it’s from [1] which is linked from [2]

[1]: https://mobile.twitter.com/GPUsAreMagic/status/1256866465577...

[2]: https://travisdowns.github.io/blog/2020/05/26/kreg2.html

> it’s less than 5% of the die

It would be equally fair to say that the same die uses less than 5% of it's space for the integer ALUs. It could also be said that the decode unit is so complex that it takes as much die space as all the integer ports put together.

SRAM may use most of the die, but it isn't using huge amounts of power most of the time as it's static. Those big SIMD units are also powered off when not used (no doubt it's the same with the other ALUs).

In contrast, the entire 5% of the die that makes up the decoder never power gates and is always running flat out. By size it's the same as leaving all your integer cores running full-out all the time.

The bigger issue seems to be that neither AMD nor Intel have been able to make those units much wider over the years which puts a hard limit on total throughput (they've hinted that the power cost on widening the decoder is very big which would mean loads of power used for diminishing returns).

It isn't so much the decoder space, but the decoder complexity that is the disadvantage of x86 chips. The problem is that the instructions have varying lengths. Only when it has decoded an instruction, the chip knows where the next instruction starts. ARM-instructions are all the same length, so the instructions can be decoded in parallel without "knowing" the previous instruction. That lets Apple go much wider (8 instead of 4) with the instruction decoders.

Reply on news.ycombinator.com