A14 - what version of the arm architecture ?

[MalcolmH]

I just read that the DTK doesn’t support virtualisation. I assume with is because the a12 chip uses an early version of the arm8a architecture.

What version do you think the a14 is using ? Has this been announced ?

AArch64 - Wikipedia

en.m.wikipedia.org

is it too early for armv9 ?

 

[thenewperson]

is it too early for armv9 ?

Some are speculating it will be v9 but I'd be very surprised.

 

[TylerL]

The transition comes at a strange time, as Apple's always been on the cutting edge of ARM architectures, being the first to jump to ARMv8.

Apple is committing to supporting all existing ARMv8 iOS apps on Apple Silicon Macs.
And, unless Apple is planning on overnighting new DTKs to developers in the next month with a whole "haha we fooled you but it's still really Just One Checkbox to Port" schtick, the A14 is probably just another ARMv8 variant.

...but does that mean early adopters of Apple Silicon Macs will be behind the times just a year into their lifecycle — like the 32-bit Intel Macs were when 64-bit machines hit the market only 6 months later?

 

[Superhai]

...but does that mean early adopters of Apple Silicon Macs will be behind the times just a year into their lifecycle — like the 32-bit Intel Macs were when 64-bit machines hit the market only 6 months later?

I doubt that ARMv9 will introduce an entire new mode, at least if it is coming in the very near future (something I also doubt, I rather think v8.7 and some new instructions). If there are a large number of changes, some kind of hypervisor implementation will support older code (or a separate compiled arch in combined macho file as is done to support x86). But I think older CPUs will be supported with not implementing the newer instruction sets unless really needed, or by exception handlers as is typically done today.
For early adopters being behind, yes of course, I hope there will be bigger yearly changes, because the last couple of years there have been few leaps and bounds due to the x86 CPUs.

 

[Kostask]

Apple stated that there is a hypervisor core/processor in the Mac AS SoC. Whether it is compliant to some spec that ARM puts out really isn't a consideration, as there are other AS accelerators that don't fit within the ARM specs in any way. Even if Apple does as some point decide to go to the V9 ARM specification, it will probably keep using its own, in-house hypervisor processor, if they deem it to not fit within their eco-system/software design.

 

[Joelist]

Remember all Apple uses is the instruction set and they add a lot of their own commands to it. The microarchitecture is 100% Apple designed, and actually resembles the Intel Core 2 microarchitecture more than anything else.

 

[cmaier]

Remember all Apple uses is the instruction set and they add a lot of their own commands to it. The microarchitecture is 100% Apple designed, and actually resembles the Intel Core 2 microarchitecture more than anything else.

What commands do they add to it?

 

[leman]

What commands do they add to it?

Real World Technologies - Forums - Thread: Apple Math/Matrix (?) Extensions

www.realworldtech.com

 

[Joelist]

Real World Technologies - Forums - Thread: Apple Math/Matrix (?) Extensions

www.realworldtech.com

Thanks for posting one example! I've been tied up today.

 

[cmaier]

Real World Technologies - Forums - Thread: Apple Math/Matrix (?) Extensions

www.realworldtech.com

Awesome, thanks!

I’ve long felt the end point of all this is Apple eventually going to their own ISA entirely. Main advantage of ARM for them at this point is probably IP indemnification for patents that read on the instruction set. I doubt they care at all about maintaining compatibility with other OS’s at this point.

 

[Joelist]

I agree that in the longer term Apple will eventually announce their own ISA and save themselves the licensing money. Because of the way their ecosystem works they can provide developers easy means to recompile their apps and such.

 

[theorist9]

I read one small group that might have an interest in the AS Mac Pro consists of those who are, or will be, doing development work for ARM clusters. I guess this means they'll be out of luck.

 

[leman]

Awesome, thanks!

I’ve long felt the end point of all this is Apple eventually going to their own ISA entirely. Main advantage of ARM for them at this point is probably IP indemnification for patents that read on the instruction set. I doubt they care at all about maintaining compatibility with other OS’s at this point.

I don’t see much advantage in a custom ISA. ARM is established, well designed, validated, it has tools, mature compilers and industry support.

Now, little ISA extensions- sure. Like Apple Silicon that’s reported to have switchable memory ordering mode to support x86 emulation. Or the DSP extensions. Note that AMX is hidden from the user, the only way to take advantage of it is via Accelerate framework.

 

[leman]

I read one small group that might have an interest in the AS Mac Pro consists of those who are, or will be, doing development work for ARM clusters. I guess this means they'll be out of luck.

I think this is one of the interesting benefits of Apple going ARM. ARM servers are very attractive for backend development due to their lower operational cost, and SVE is one of the best designed HPC extensions I have ever seen (my opinion of course). ARM Macs could stimulate development in this area and give programmers who use them a competitive advantage.

 

[Superhai]

ISA extensions are nothing new. This was also an issue with the jump from PPC to Intel. AltiVec had to be implemented using Intel SIMD extensions. And today AMD and Intel use different extensions, although they eventually end up copying each other’s. Apples extensions to the ARM is not very well documented as far as I know, but the majority of developers should not need to use them, but rely on libraries or the compiler (not sure how much Xcode clang is aware of Apples customisation).

Going forward however I hope Apple will provide documentation on their cpus as Macs as opposed to their other devices do stuff that Apple not always envisioned. Apples libraries and frameworks are extensive, but specialist developers may want to experiment. Especially in the new world era of AI and heavy number crunching.

 

[leman]

Going forward however I hope Apple will provide documentation on their cpus as Macs as opposed to their other devices do stuff that Apple not always envisioned. Apples libraries and frameworks are extensive, but specialist developers may want to experiment. Especially in the new world era of AI and heavy number crunching.

The advantage of keeping some stuff private is that Apple has more freedom in experimenting with things. E.g. they could just remove all the AMX stuff from the CPUs and leverage Neural Engine instead in some future chip.

Personally, I would be more than happy if Apple gives us SVE/SVE2

 

[cmaier]

I don’t see much advantage in a custom ISA. ARM is established, well designed, validated, it has tools, mature compilers and industry support.

Now, little ISA extensions- sure. Like Apple Silicon that’s reported to have switchable memory ordering mode to support x86 emulation. Or the DSP extensions. Note that AMX is hidden from the user, the only way to take advantage of it is via Accelerate framework.

I can see some advantages. “Mature compilers and industry support” isn’t all that relevant - LLVM will take care of that, and there isn’t really any “Support” apple relies on outside of its own walls.

As for advantages, I can think of some. ARM is not an ideal architecture - it’s much cleaner than x86, but there’s a lot of historical weirdness in it. I can see Apple rethinking things. And, of course, as far as Apple is concerned, the iSA should be hidden from the user. Everything through frameworks (metal, accelerate, etc.). So if they find that they are running into a bottleneck because they don’t have enough registers, or they have some legacy junk (e.g. arm’s conditional execution support), I could see Apple starting from scratch. In fact, I would be shocked if they aren’t already playing around with it. Or they may want to add support for things like hybrid accumulator/register instructions (register file hierarchy), or untagged load/stores, that are good for power consumption. Etc.

 

[theorist9]

I think this is one of the interesting benefits of Apple going ARM. ARM servers are very attractive for backend development due to their lower operational cost, and SVE is one of the best designed HPC extensions I have ever seen (my opinion of course). ARM Macs could stimulate development in this area and give programmers who use them a competitive advantage.

Given that Apple is adding its own extensions, would that not preclude using an AS Mac Pro for development work for an ARM-based HPC cluster? Or are you saying that, even if the chips in the HPC were designed to be used with a standard ARM ISA, they could still work—and potentially work better—with Apple's extended instruction set?

 

[leman]

Given that Apple is adding its own extensions, would that not preclude using an AS Mac Pro for development work for an ARM-based HPC cluster? Or are you saying that, even if the chips in the HPC were designed to be used with a standard ARM ISA, they could still work—and potentially work better—with Apple's extended instruction set?

As long as you are not relying on any extensions explicitly (it’s not like Apple makes them visible to the user anyway), does it really matter? I would expect the behavior to be consistent across various ARM CPUs, so one should be able to develop and test on Apple and then deploy to the cloud.

 

[theorist9]

As long as you are not relying on any extensions explicitly (it’s not like Apple makes them visible to the user anyway), does it really matter? I would expect the behavior to be consistent across various ARM CPUs, so one should be able to develop and test on Apple and then deploy to the cloud.

This is out of my wheelhouse, so I'm just asking, but here's what I had in mind:

Suppose a developer is trying to optimize code for maximum performance, and he's comparing two ways of getting the same thing done, which we'll call code block A and code block B. It so happens that (without the dev's knowledge*), block A makes use of Apple's extended instruction set, while block B does not. As a consequence, code incorporating block A is faster on the AS Mac Pro than that using block B.

However, when deployed on the cluster (which does not have Apple's extended instruction set), B is faster than A.

Hence the AS Mac Pro would not be a good tool for doing such development testing unless it would be possibe to implement that same extended instruction set on the ARM cluster itself.

*You wrote that the extensions aren't visible to the user, suggesting to me that devs could be unaware which instructions are actually used to implement their code.

***************
Come to think of it, if you're spending 10's or 100's of millions for a new supercomputer, wouldn't it make sense to purchase, along with it, several custom workstations (for development work) that use the same processors, and as close as possible to the same architechture, as the supercomputer itself? It seems that's the only way you could do processor-specific (e.g., accounting for the sizes of the various levels of cache) and architechture-specific optimizations using workstations.

 

[Superhai]

As a consequence, code incorporating block A is faster on the AS Mac Pro than that using block B.

This also happens with different cpus even if instructions are documented. But there are options in compilers to use certain instruction sets.

I’m not sure what you mean by invisible to users. If you use a disassembler the opcodes may not turn into something if it is not aware, but if you really want you should be able to reverse it into something legible.

 

[Superhai]

Come to think of it, if you're spending 10's or 100's of millions for a new supercomputer, wouldn't it make sense to purchase, along with it, several custom workstations (for development work) that use the same processors, and as close as possible to the same architechture, as the supercomputer itself?

Well, you typically rent space and don’t own the supercomputer. But of course a processor of same type is most ideal.

 

[leman]

Suppose a developer is trying to optimize code for maximum performance, and he's comparing two ways of getting the same thing done, which we'll call code block A and code block B. It so happens that (without the dev's knowledge*), block A makes use of Apple's extended instruction set, while block B does not. As a consequence, code incorporating block A is faster on the AS Mac Pro than that using block B.

Except you can’t write block A at all since Apple does not expose their extensions publicly. My hope is that Apple introduces SVE support, which is an official ARM extension and will be compatible by ARM HPC.

As to your idea about getting workstations with same CPUs, yes, it course, but it’s not always feasible. These HPC and Server CPUs don’t necessarily come in workstation format. And if you are a startup looking to deploy your backend at an ARM cloud server to save money, or a university researcher using a shared cluster to do HPC work, a 60k+ workstation is usually both out of your reach and an overkill.

 

[theluggage]

Except you can’t write block A at all since Apple does not expose their extensions publicly.

...because instead of "block A" you're supposed to write a version which uses an official MacOS framework like Metal or Accelerate - either directly or though an industry-standard-to-MacOS wrapper library - which gets continually optimised by Apple to use their latest hardware where available. That way, come 2028, when Apple decides to switch to the Risc-VII, x86-128 or Apple96 architecture, everything will just get automatically translated and only the developers working on MacOS itself will notice.

And if you are a startup looking to deploy your backend at an ARM cloud server to save money, or a university researcher using a shared cluster to do HPC work, a 60k+ workstation is usually both out of your reach and an overkill.

...except it is 2020 and (Google tells me) you can spin up an ARM server in the cloud for 50 cents an hour (if not for free) and do the testing on an exact clone of the production system rather than some approximation you've put together in VMWare.

If you're going to hand-optimise your code for a specific processor implementation, you need access to the specific hardware (meatspace or virtual) for testing/tweaking at some point... and the issue is just as true of x86 if you're comparing i3 vs. i9 vs. Xeon vs. AMD. Apple can't wave a magic wand and make that not so. However - 90% of projects shouldn't need that, and even when they do, 90% of the development work can still be CPU independent.

...heck, a lot today's work is being done in Python or Javascript anyway...

It's tempting to say "OK, we're losing x86 compatibility, but we're gaining ARM compatibility!" but, really, just as the need to have an x86 laptop/desktop to develop for x86 targets can be overstated, the advantages of having an ARM laptop/desktop can also be overstated. The vast majority of modern development work is CPU independent (esp. if 64 bits, little-endian is a given and you're targeting modern OSs with good hardware abstraction frameworks) and the fractions-of-a-project that are the exceptions to that rule can't/shouldn't realistically be done without access to the real hardware.

 

[theluggage]

What version do you think the a14 is using ? Has this been announced ?

Apple A13 - Wikipedia

en.m.wikipedia.org

Instruction set: A64 – ARMv8.4-A[1]

...OK that's the A13 but I doubt that they'll backtrack.

Anyway, they showed virtualization running on Apple Silicon (of an undisclosed version) at WWDC. Launching anything bigger than a 12" MacBook with a CPU that didn't support virtualization* would be a... courageous move.

OTOH the DTK is there for one reason only: to let rank-and-file developers compile and test their apps on ARM at a time when prototype A14 silicon (if it exists at all) is rare and expensive. They don't need virtualization for that and, since there likely won't ever be another A12-based Mac, optimising the MacOS hypervisor framework for the A12 (which I'm guessing is what Parallels will be using exclusively on AS) would be a waste of time...

Important not to confuse "does not support" with "is incapable of supporting" - e.g. if Apple have disabled/not yet implemented the Hypervisor framework on the DTK, or even if Parallels for ARM is not available to developers without NDAs up the wazoo then it "does not support virtualization".

The CPU features in question are extra instructions that make virtualization more efficient - not what make it possible. There's also the red herring "Rosetta2 won't run x86 Hypervisor apps" which actually means that "you can't run the current x86 versions of Parallels/VMWare/Docker on ARM using Rosetta" (film at 11!!!)