A curious rumor. I believe publicly since June 2024, Arm's X925 Technical Reference Manual confirmed it does not support SME:
CTRL / ⌘ F "SME":
Perhaps next or next year.
CTRL / ⌘ F "SME":
Perhaps next or next year.
I wonder how these guys can get it wrong when official documentation is available. It tells a lot about literacy in the modern world.
SME is only the X925 core
Edit:
Not true
SSE is 128-bit like NEON so in a way it's like-to-like, but I agree with you he should use native flags when compiling. And switch to a more recent version of clang. The question being: does he still have access to the CPU he makes comparisons against?Is Geekerwan still using clang 14.0.6 without any march flags? If so just keep in mind that for ARM64 <-> x64 comparisons in Spec, x64 will not use anything better than SSE while ARM will use Neon [as it cannot use anything better anyway], in other words AVX+ will be unused on x64 targets. Which will affect the scores to some degree. Now, I am not saying his methodology is wrong, just to keep this in mind as this is a consequence of the setup he is using.
On the throughput front yes, but if AVX2 is available then you get 2x the throughput with the same number of instructions, something that will help x64 if compiler decides to use it But of course this then depends if you want to even the playing field, or show best side of each CPU. I wish when presenting SPEC results reviewers would have a brief paragraph about consequences and motivation of their compiler choices, leaving their audience more aware of what is going on.SSE is 128-bit like NEON so in a way it's like-to-like, but I agree with you he should use native flags when compiling. And switch to a more recent version of clang. The question being: does he still have access to the CPU he makes comparisons against?
You're preaching to the choirOn the throughput front yes, but if AVX2 is available then you get 2x the throughput with the same number of instructions, something that will help x64 if compiler decides to use it But of course this then depends if you want to even the playing field, or show best side of each CPU. I wish when presenting SPEC results reviewers would have a brief paragraph about consequences and motivation of their compiler choices, leaving their audience more aware of what is going on.
Based on their official slide, it does pretty damn well in that regard. Better performance at lower power all throughout the curve.What if A725 don't scale well under 1W?
It was a massive jolt to the industry:Yes Arm had to up the game, though it has to be seen how high X925 can be clocked in devices. IPC is not the whole story.
IMHO Arm upped the game starting with Apple first 64-bit chips which caught everyone by surprise. This can be seen for instance in David Huang perf per clock on SPEC for various Arm chips, many of which precedes Qualcomm chip. Just remember a CPU needs several years of development.
It was a massive jolt to the industry:
That Apple released its implementation so soon after the ARMv8 spec announcement started a bit of continuous shock-and-awe. It's likely Apple submitted its implementation as the 64-bit standard working closely with ARM and kept running with that lead for years. ARM's own implementations in the A57 were jokes in comparison and were a disaster for Qualcomm in the 810/808 era. (One almost wonders why Apple didn't just keep the ISA for itself and its ecosystem...)
Qualcomm isn't so different here in that its initial implementations for cellular air interfaces are submitted to the 3GPP as the standards for generations of cellular networks. (Except designing and implementing these designs across net connected towers and mobile subscription stations are far far more sprawling, difficult, and more capital intensive to this day. CPU design is much more relatively self-contained and much more available even for high performance designs.) It is a good thing that Qualcomm has submitted these standards and is bound by SEP licensing terms here or cellular network deployments would be in a more fractured and primitive shape or in the hands of those with politically questionable motives (to some).
Apple's lawsuit and withholding of cellular royalties to Qualcomm was a real kick to the nuts, and its acquisition of Intel's modem unit was a bit of a parting shot on the way out the door when the lawsuit failed. Qualcomm is getting its shot back after the contested departure of lead Apple CPU designers now with its still hotly contested acquisition of Nuvia (very questionable and public lawsuit by ARM; if it cared to truly expand its ecosystem, why not quieter arbitration?). With Qualcomm an essential enabling force for Android SoCs which are often foundationally cheaper due to their better integration of modems (I wouldn't rule out Qualcomm helping android ecosystem partners with modem and RF implementation), I think this is much more of an active but cold-war than people suspect.
Former iOS kernel programmer:I don't buy for a second that "Apple submitted its implementation as the 64 bit standard". In fact, this is provably false. ARM announced ARMv8 / AArch64 in October 2011, and Apple shipped their first 64 bit ARM implementation in the iPhone 5S in September 2013, almost two years later. The tapeout deadline would have meant its design was complete a year after ARM's official announcement. What Apple taped out pretty much the same time as ARM's announcement was the A6, which included Apple's first custom core design.
Apple did not have an "implementation" to submit prior to October 2011 - and it would have been well prior to that because you can't just turn around the volume of documentation ARM provides in a week or a month. It is well known that Apple worked with ARM to define AArch64, so they would have had early knowledge of what it contained, allowing them to use that information as A7's design was underway. They were aggressive in pushing it out as early as they reasonably could have, that's all. Not sure why people think that ARM would allow a third party to define something as important for their future as their 64 bit ISA. For an optional feature like SME, sure, I could buy that Apple designed AMX and then told ARM "hey do you want this to be a part of the standard" and it was tweaked a bit, had its name changed, and became SME. But not for AArch64, not a chance!
The reason everyone else was left behind is because while ARM's designers could have used the early information to work on a 64 bit design like Apple did, they chose not to do so. Supposedly people in ARM itself were caught flat footed by how quickly Apple shipped their first 64 bit design, so I presume Apple kept that secret as long as they could. I believe there is some requirement for architectural licensees to pass conformance tests, but Apple could have waited until a couple months before the A7/iPhone 5S was released, and ARM may have assumed what was being submitted to them was an early prototype of something shipping in a year rather than a month.
Can you paste the Twitter quotes? That site seldom works for me and I can't view it.Former iOS kernel programmer:
I think it's fair to say that Apple had a very big part to play in the ISA design, modeling and prototyping. They may very well have had a u-Arch already well underway prior to discussing with ARM the details of how a compatible ISA would look.
The things that make the M1 good have nothing to do with ARM. That cache is impressive.
1) The premise here is wrong. arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches.
2) Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others.
3) ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013.
4) Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided.M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
They called it the Apple ISA but then contradict themselves in the very next points?Replying to David Kanter's post:
"The things that make the M1 good have nothing to do with ARM. That cache is impressive."
The point: it is clear that ARM's 64-bit v8 ISA adhered closely to the u-Arch apple was developing internally if those posts are to be believed. Apple was far from a standard 3rd party in this relationship. Standardizing and polishing an instruction set / binary interface against that u-arch design for ecosystem compatibility wasn't the heavy lift, but having such clout in shaping the ARMv8 spec certainly set Apple up then for performance domination in the years to come.If I'm reading that it sounds like Apple contracted ARM to design a 64 bit ISA extension. And that they did. Not that Apple designed ARM v8.
It’s not others we’re not allowed to implement Apples designs, it’s that for the scope of a phone. Those cores were enough and ARM didn’t care to make beefy cores. Apple’s whole goal was to replace Intel on the Mac and it needed beefy cores and a laid out a plan.ARM's and other vendors' u-arch implementations of this ISA for the Android side were never quite as wide as Apple's each product year and contained questionable structures like micro-op caches that were eventually removed and never saw the light of day in Apple's implementations. They were clearly not allowed to re-implement Apple's designs for the broader ecosystem, and
Being a developer, iOS kernel or not, doesn't give you the full picture, far from it. He might be partly right. Or not.Former iOS kernel programmer:
I think it's fair to say that Apple had a very big part to play in the ISA design, modeling and prototyping. They may very well have had a u-Arch already well underway prior to discussing with ARM the details of how a compatible ISA would look.
I think it's much more plausible than not, much more consistent w/ the unusual course of events, and no one has presented anything convincing to disprove this assertion.Being a developer, iOS kernel or not, doesn't give you the full picture, far from it. He might be partly right. Or not.
People involved in the matter are not allowed to talk. The others are just guessing, or risking a professional fault and being fired for disclosure.
I agree with you that it looks more or less plausible (but I disagree with some of his claims).I think it's much more plausible than not, much more consistent w/ the unusual course of events, and no one has presented anything convincing to disprove this assertion.
That part is so obvious (just read official release announcements), it's not even worth mentioning , and doesn't prove the rest of the message of the iOS dev is correct. No need to be an iOS kernel dev to know.Most notably:
Apple's implementation came much earlier than even ARM's own.
Again this doesn't prove the Twitter/X message you quoted is correct.Apple's implementation of ARMv8 beat the pants off of ARM, Qualcomm, Samsung, and nVidia's implementation for years as they continued to ride this lead making steady and incremental improvements on the original, Haswell-sized design. ARM's own implementations were much more choppy in their pace of improvements; compare A72 -> A73 vs A75 -> A76 or X4 -> X925. ARM's designs are also much more heterogeneous in structure with various lineages eg. (A57->A72) (A73->A75) (A76->X3 u-op caches) etc.
Unproven.1) The premise here is wrong. arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches.
First part unproven. Second part is obvious, read official announcements.2) Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others.
Obvious: Arm is here to sell to its customers, Apple is just one of them. Before Apple released a 64-bit CPU, no one cared, so Arm didn't have to push it as quickly.3) ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013.
One could do that with 32-bit Arm.4) Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided.M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
Yes, the vertical integration Apple can afford does wonders.it’s no surprise Apple was ahead, they had the right people, plan and acquisitions. The PA Semi being one of the notable ones.