Hacker News Reader

Comment by enos_feedler | Hacker News Reader

I think the narrative around instruction set is a bit overblown. I was a chip architect for the shader core at a major GPU company. I worked on simulators and modeling performance for next generation chips where we changed the ISA for each family of chips. The big reason why Apple Silicon is so damn fast is because they were able to shape the design at modeling time exclusively around Mac system level workloads. At best, Intel would have some subset of traces come from Apple for important traces to optimize for. Combine getting to narrow traces down exclusively for one platform, and heterogeneous design space (cpu + coprocessors) and you can really tune a monster.

View on HN

> The big reason why Apple Silicon is so damn fast is because they were able to shape the design at modeling time exclusively around Mac system level workloads

Is that really the case? My understanding was that M1 is fast because it's able to keep the chip saturated with instructions due to a large L1 cache and wide instruction decoders. Is anything about that specific to mac workloads?

> Is anything about that specific to mac workloads?

The memory and instruction architecture may be more 'generic' but it and the neural engine, storage and media controllers, image processor etc will have been shaped and fine tuned by the requirements of the mac.

It is probably the marginal gains of each subsystem being 5-10% better for purpose that gives it the edge.

It's mostly just inertia.

https://images.anandtech.com/doci/16226/perf-trajectory_575p...

Interesting!

Compare https://slatestarcodex.com/2019/03/13/does-reality-drive-str...

Does optimizing for a single system really improve performance significantly in general purpose computing benchmarks like SPEC? IIRC, the M1 also does fairly well with virtualized Linux.

It does. The point is how Apple could use so much silicon space for the CPU in the SoC. Most AP and CPUs are designed to be general purpose as possible, so there are some spaces used for unnecessary interfaces. But Apple could use those spaces for CPU. Also Apple could increase the die size without thinking about profit in chip production because they earn money from their devices, so by selling SoCs like others. No other companies can do silicon business like Apple.

That doesn’t sound reasonable to my (electrical engineer but 15 years since last involvement in processor design) ears.

Intel has enough product lines that there are no “unnecessary interfaces”; what were the unnecessary interfaces in the Intel chip used by Apple?

Similarly, so does Qualcomm and the tens of other of ARM licensees - any mass market design can find or customize a core with no meaningful dead weight.

It may be a contributing factor, but I have not seen anything to indicate it’s very important.

I give the “many small things done right” theory much higher likelihood - just as in the case if the iPhone, there wasn’t any specific thing that wasn’t done before - except for a winning combination.

> what were the unnecessary interfaces in the Intel chip used by Apple?

Everything Management Engine related, for one.

Do we have any indication apple has a similar management cpu buried somewhere?

All the new models have the T2 chip.

AVX512 is a waste of transistors for most workloads.

Yes. But Apple has the neural accelerators which are a waste of transistors for most workloads, and Intel has a bunch of chips without AVX512.

So that does not fit the GPs claim that the M1 is fast because Apple does vertical integration and others have to support many systems.

"But Apple has the neural accelerators which are a waste of transistors for most workloads"

Based on?

Many Apple frameworks tie into those accelerators; including frameworks like Metal that one wouldn't necessarily expect.

Another strength of Apple - as a programmer your workloads can gain automatic acceleration as frameworks are extended to leverage new hardware. Note this isn't anything new; it's been going on for years already.

The M1 runs Windows through virtualization faster than Windows runs natively on Qualcomm ARM.

People need to stop saying stupid stuff like "It's only fast because it's so intensely focused on macOS."

Apple silicon is plenty fast at “non-Mac” workloads.

How do you run an M1 not in a Mac? It only runs with apple RAM and Apple IO and apple firmware.

I assume the parent means UNIXy tools which target ARM broadly are still very fast on Apple Silicon. Not to mention VM performance.

But your point, that there's still a lot of Apple stuff at play there, is a fair one. It will be very interesting to see how (native) Linux runs once that porting effort gets more under way...

being "a chip architect for the shader core at a major GPU company" sounds like a dream job for me. Do you have any interesting tips or books to read for a fellow hardware design engineer? :)

I don't see how an ISA doesn't matter. While not a chip architect like you, I do work as a developer and I know that the interface you make to something affects what kind of performance you can build in the backend.

In principle whether you are using Python or C++ doesn't matter. It is just an interface. The compiler or interpreter in the back decides the actual performance. Yet it is pretty obvious that the specifications of C++ syntax makes it much easier to create a high performance compiler than the specification for Python.

I have been quite involved with Julia. It is a dynamic language like Python, but specific language syntax choices has made it possible to create a JIT that rivals Fortran and C in performance.

Likewise we have seen from Nvidia slides when the went with e.g. RISC-V over ARM, that the simple and smaller instruction-set of RISC-V allowed them to make much cores consuming much smaller silicon, better fitting their silicon budget.

When you worked as a chip architect didn't the ISA affect in any way how hard or easy it would be for you to make an optimization/improvement in silicon?

I mean if one ISA requires memory writes to happen in order, or have variable length, or left too little space for encoding register targets etc. All that kind of stuff is going to make your job as a chip architect harder isn't it?

Also I don't quite get your argument about modeling the M1 around Mac workloads. We know the M1 is having great performance on Geekbench and other benchmarks which have not been specifically designed for Mac workloads.

Only things I can see with M1 which is specific to Mac is:

1) They do the code needed for automatic reference counting faster. Big deal on Mac since more software is Objective-C or Swift which uses automatic reference counting.

2) They prioritized faster single cores over multiple cores. Hence optimizing more for a desktop type workload than a server workload.

3) A number of coprocessors/accelerators for tasks popular on Macs such as image processing and video encoding. But that is orthogonal to the design of the Firestorm cores.

I don't claim to know this remotely as well as you. I am just trying to reason based on what you said and what I know. Would be interested in hearing your thoughts/response. Thanks.

It's not the C++ syntax that makes it fast, it's the semantics.

Yes but that is all included in an ISA. A CPU ISA specifies opcodes as well as semantics. Together that affects what optimizations you can do. Or rather how much silicon and brain power you need to accomplish it.

Does this potentially mean that as the OS evolves, the chip will likely become less efficient, as it becomes "out of tune"? Apple could mitigate this obviously.

Reply on news.ycombinator.com