When I've been micro-optimizing performance-critical code, integer division shows up as a hot spot regularly. I assume most developers don't think about the performance implications of coding up a / or % between two runtime values, preventing the compiler from doing any strength reduction. Apple must have seen this in their surely voluminous profiling of real-world applications.
Let's enumerate what Apple has access to in more detail:
- third-party apps (in bytecode form)
- first-party apps
- the kernel
- a vast array of performance-critical libraries
- c/swift compilers
- machine code optimizers
- silicon design
- product stakeholders
And unlike Intel or Microsoft, everyone at every layer of Apple knows that their success will ultimately be judged on the same, singular metric: the quality/performance of the Apple product being released in September, and then the Apple product being released next March. That kind of unified focus is almost unheard of in the commodity PC space.
To get the same level as access as Apple, Intel would have to cut a deal with Microsoft for access to their most sensitive telemetry data (and - likely - also to modify windows to collect more).
I think it's quite unlikely that MS would agree to that readily, if at all.
Apple doesn't have any such conflicting motivations because they sell the product rather than commodity parts. For Apple, improving the compiler as a unified part of the Apple Silicon development process means they can sell a better product with the same unit cost, with only residual benefit to competitors that don't have access to Apple Silicon hardware.
It's the packaging of all tools and libraries that Intel provides, extending to much more than "a compiler".
tl;dr 80 developers working on an open stack, even with coordination friction, are going to outperform 20 developers on a closed stack.
It also assumes that more developers is inherently better. For a rebuttal, see The Mythical Man Month.
It's fair to say that three choices is better than two, but every additional choice will have diminishing returns. And at some point, the chances of an additional choice having any novel appraoach or distinctive features approaches zero.
Using what metric?
Keep in mind what calling conversions are:
"Calling conventions act as a contract between subroutines at the assembly level."
https://levelup.gitconnected.com/x86-calling-conventions-a34...
This example is pretty artificial - I can't really think of an optimization you could make knowing that you rarely turn left (maybe something with the axel?) but yea - more data means that you can turn your product to behave better in optimal situations - this comes at a cost but if you have a big stack of data you can make it so that your product generally wins that trade off most of the time.
1. https://www.bromfordlab.com/lab-diary/2019/4/9/why-do-ups-tr...
A real-world example are old NASCAR race cars. Optimized heavily for turning left, they were quite good at it at the expense of turning right.
Also keep in mind that this Xeon might not be really made for number crunching (not really sure)?
An other possibility is that Apple has a very different profiling base e.g. iOS applications, whereas Intel and AMD would have more artificial workloads, or be bound by workloads / profiles from scientific computing or the like (video games)?
A compiler code generator that knows about a hypothetical two divide units (or just a much more efficient single unit) could be much more effective statically scheduling around them.
I’d guess that the bulk of the software running on the highest margin Intel Xeons was compiled some years ago and tuned for microarchitectures even older.
I'm still completely blind to how they are actually used but GCC and LLVM both have pretty good internal representations of the microarchitecture they are compiling for. If I ever work it out I'll write a blog post about it, but this is an area where GCC and LLVM are both equally impenetrable.
What can definitely play a role is that (I don't think it's as much of a problem these days, but it definitely has been in the past) is the standard "benchmark" suites that chipmakers can beat each other over the head with e.g. I think it was Itanium that had a bunch of integer functional units mainly for the purpose of getting better SPEC numbers rather than working on the things that actually make programs fast (MEMORY) - I was maybe 1 or 2 when this chip came out, so this is nth-hand gossip, however.
Now I'm really curious. In my experience, integer division practically never happens (except by powers of 2 that are easily optimized down to a shift), to the point where I was frowning in puzzlement about why Apple spent resources optimizing it.
How is the code you are looking at, bottlenecking on integer division? What on earth is it doing, to make that a frequent operation?
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...