Comment by menaerus | Hacker News Reader

Comment by menaerus | Hacker News Reader

Parent Full thread

> They design chips and market them. They do both things like no other company on this planet.

Latter for sure, former not so much. Apple is not designing its own CPUs (but ARM does) nor they are physically manufacturing or improving the silicon process (but TSMC does), they build SoCs like many other companies out there. This means that they can't make an advantage over the competitors by:

  1. Making the silicon process more advanced
  2. Improving CPU microarchitecture
  3. Improving CPU instruction pipeline
  4. Improving CPU branch prediction or OOO execution
  5. Making the TLB page-walker algorithms more efficient
  6. Making better cache-coherency protocols
  7. Implementing their own bus interconnect which is faster than others
  8. Designing better RAM modules
  9. Etc. etc. (I could go on and on but I guess the point is visible)

What Apple can do to make a difference is that they can fine tune the SoC microarchitectural details but hardly anything else. By looking at the specs of M1's, the biggest outliers with respect to other chips of the same or similar class currently existing on the market are:

  1. RAM and CPUs are physically co-located on the same die
  2. RAM is advanced to (LP)DDR5
  3. CPU caches are massive (L1, L2 and TLB)
  4. There's a separate cluster of CPUs for low-power mode execution

First three things from the list is what is making M1's so fast, and especially the third point. Enlarging CPU caches has been done by the server CPUs like forever and which is the reason why quite old (2014) 2x Xeon system can eat AMD Ryzen 9 5950X for breakfast in some of the multicore workloads I ran (and I mean substantially). Last thing from the list above is what is making this chip more power efficient and this technique is as old as the moment when big.LITTLE was introduced in 2011. In nowadays ARM chips it is known as DynamIQ but the concept is the same: conserving energy by running less power hungry CPUs when workload does not require the full power (which in average user is most of the time).

Almost all of this is inaccurate. You can read about their silicon program in pretty much any trade magazine for details but for example: their main cores have been in-house designs for about a decade, RAM is on-package not on-die, that is probably only a moderate perf win in itself, they have been contributing to and extending the ISA for many years, etc.

What the Apple chips do appear to be is a successful application of the "lead bullets" approach to good engineering. If you compare to Zen 2 it's clear that Apple's designs are not really incomparably better than peers, but they are excellent. With the advantage of better software support and a better manufacturing process than other mobile CPUs they perform really well.

They don't directly compete with CPU vendors but hopefully their new products light the fire under their PC counterparts to build better products. I sure hate feeling trapped in their super buggy software ecosystem.

I think one thing that has been fairly unique in the industry is that Apple has been willing to throw silicon die area at a problem. For example, their cache sizes are massive in comparison to anything else in the consumer space.

If you sell chips to device manufacturers for a living, increasing die size cuts directly into how much you make per wafer.

When you sell devices containing your own custom chips, your profit margin does not depend on the cost of fabbing that chip alone.

As a bonus, when everyone else is trying to make a smaller die and cranks up the clocks for performance, you are hugely more power efficient (without giving up performance) when you throw die size at an extra wide instruction decode with a ton of execution units running at a much slower clock speed and have huge reorder buffers so you can track more instructions in flight.

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

It's an interesting hypothesis, I'm not sure how true this is. The newer Ryzen 3 and upcoming Alder Lake products are between M1 and M1 Pro sized, and they all have similar total amounts of cache. Arguably by using both a bit more area and a more advanced process Apple has a much higher transistor budget to work with, but throwing more transistors at the problem doesn't necessarily help power efficiency. The one area where they have a really decisive advantage is their ability to synchronize OS development with hardware roadmap, then force developers to play along (via app store rules).

>The newer Ryzen 3 and upcoming Alder Lake products are between M1 and M1 Pro sized, and they all have similar total amounts of cache.

Increasing the cache sizes to be as large as Apple's phone SOC is an extremely recent decision on AMD and Intel's part, as noted at the M1 introduction.

>Last year we had speculated that the A13 had 128KB L1 Instruction cache, Apple has confirmed that it’s actually a massive 192KB instruction cache.

That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

> throwing more transistors at the problem doesn't necessarily help power efficiency

Getting your performance from IPC improvements at a lower clock (at the cost of die space) instead of pushing the power envelope to hit ever increasing clock speeds seems to be paying off quite well.

Ah true, in phone land the differences are extra stark. Given the lower margins and lack of service revenue on the Android side it's not clear if it's economically feasible for Qualcomm etc to match them. It's possible we'll see something similar happen on the Mac side where a something like a M1 Max iMac resets the bar for workstations. Then again maybe not, most laptops still have terrible screens despite Apple showing it's a solvable problem at least five years ago.

With Phones, using a wide CPU design that runs at a lower clock has been Apple's strategy for quite some time.

For instance, when power leakage became a huge issue at 20nm, Apple was less affected since they ran their clocks so much lower.

>Apple is something of the exception here, with the 20nm A8 proving to be a solid SoC, thanks in part to their wide CPU design allowing them to achieve good performance without using high clockspeeds that would exacerbate the problem.

https://www.anandtech.com/show/9686/the-apple-iphone-6s-and-...

Cache, maybe. But the M1 is generally a more aggressive design. Can issue more instructions per cycle, more functional units, more aggressive GPU, larger reorder window, more extra accelerators (audio, video, machine learning, etc), in package ram, more memory channels (8 x 16 bit on the lowest end M1), etc. There's substantial advantages in memory bandwidth on the higher end M1s. M1 pro = as much bandwidth as a 8 channel AMD Epyc server chip. M1 max = as much bandwidth as a 16 channel AMD epyc dual socket. Some of the M1 products don't even have fans! I have a M1 mini that runs silent fast and makes my 1 year old MBP 16" Intel i9 look pretty terrible, even if I ignore the jet engine sounding fans that turn on when patching, video streaming, or doing nearly anything but idle.

Keep in mind that most laptops have a 128 bit memory interface as do even high end desktops like i7/i9 and the ryzen 59XX. M1 max and pro are 256, and 512 bits and running at 4266 Mhz!

Performance per core near the best Intel and AMD have to offer, but perf/watt is crazy better.

I'm not super convinced by the GPUs to be honest. They seem to be good for integrated gpus, but are still blown away by discrete ones.

A lot of the issues with the GPU come down to legacy software that isn't ARM native and/or doesn't support Apple's GPU/compute API, Metal.

It's a similar situation to legacy x86 software that doesn't support AVX-512. It still runs, but could run faster if it supported the available hardware.

For example, World of Warcraft is available in an ARM native version that supports Metal and can run at 120 FPS on the 16 inch MacBook M1 Max with the graphics settings cranked up to 10.

https://www.youtube.com/watch?v=JZV3bOpv2Rs

x86 games on OpenGL don't run nearly as well, as expected.

> Apple is not designing its own CPUs (but ARM does)

Apple IS designing its own CPUs. They have been designing their own CPUs since their A4 processor.

Apple has an Architecture License with ARM [1]. Other companies with the same license include Qualcomm, Samsung, Nvidia, and Broadcom.

These licensees have full architectural freedom with the cores as long as they are ARM ISA compatible. For example, Apple has added custom instructions in their M1 processor [2].

So, an Apple ARM processor core is different from a Samsung ARM core is different from a Qualcomm ARM core.

[1] https://www.anandtech.com/show/7112/the-arm-diaries-part-1-h... [2] https://news.ycombinator.com/item?id=25559145

> as long as they are ARM ISA compatible.

And apparently in Apple's case, they get to be a little bit incompatible (no nVHE mode, crazy custom ISA extensions, ...)

Which is also obvious proof that they're their own designs, because literally nobody else could or would implement the same Apple-proprietary ISA extensions. Here, we use some of the custom instructions in m1n1:

https://github.com/AsahiLinux/m1n1/blob/main/src/gxf_asm.S#L...

That won't work on any non-Apple core.

> literally nobody else could or would implement the same Apple-proprietary ISA extensions.

That is maybe a little excessive, technically they could probably pay an other architecture license holder to do it for them.

No, because the architecture license doesn't allow it. Apple got special treatment here.

Oh, the architecture license doesn't allow bespoke ISA extension?

Nope, you need to be compatible with the architecture specification, and it lays out exactly what can be implementation defined and what can't. E.g. you're allowed some freedom in what features to implement (Apple doesn't implement EL3 and this is fine), and you can add implementation defined system registers (Apple has a huge number of them, e.g. to implement TSO for Rosetta). But you can't decide not to support mandatory features (Apple forces on VHE mode, which is not legal - VHE is optional, non-VHE mode isn't), nor can you add extensions to the core ISA. Apple added AMX, memory compression/decompression, a variant of the AT instructions that outputs to a GPR, and the whole Guarded Execution feature (two new parallel exception levels and machinery to call to/from them and lock down things to them), and possibly more, all of them in reserved instruction encoding space.

> Apple IS designing its own CPUs. They have been designing their own CPUs since their A4 processor.

That is not quite true, the A4 is an internal SoC design but commonly "CPU" in an SoC context will designate the cores (the µarch). A4 used a standard and pedestrian Cortex-A8 there.

The A6 is where they started designing the cores in-house (to very impressive and pretty universally praised results, especially for a first iteration), following which they straight nuked the entire field by releasing the first AArch64 core in A7.

> A4 used a standard and pedestrian Cortex-A8 there.

My understanding was that the A4 Cortex-A8 was a modified version by Intrinsity which apple bought out, but, you’re right. Apple didn’t start actually designing their own cores until the A6 [1].

[1] https://seekingalpha.com/amp/article/4293287-setting-record-...

> Apple is not designing its own CPUs (but ARM does)

Do you have any evidence supporting this? If you were right, it would seem odd that Apple has consistently delivered significantly better performance, often by multiple product generations, than other ARM licensees since the launch of the A8 in 2014 if ARM was doing all of the real work. Similarly, it seems like they could have saved a ton of money not hiring chip architects if they didn't have anything for them to work on.

Reply on news.ycombinator.com