Solved! ARM Apple High-End CPU - Intel replacement

[Richie Rich]

There is a first rumor about Intel replacement in Apple products:

• ARM based high-end CPU
• 8 cores, no SMT
• IPC +30% over Cortex A77
• desktop performance (Core i7/Ryzen R7) with much lower power consumption
• introduction with new gen MacBook Air in mid 2020 (considering also MacBook PRO and iMac)
• massive AI accelerator

Source Coreteks:

 

[Richie Rich]

Your argument is flawed.

First of all, the A77 is only marginally larger than the A76. PPA on the A77 is better than on the A76.

Secondly, what makes you think that Matterhorn will be the single "big" CPU offering alongside their small cores instead of it simply being the new "giant" CPU offering alongside big and little microarchitectures?

Arm not doing a giant core until now was tied to economics and their customer needs instead of their (un)willingess to actually create one.

Do you mean that ARM was able to design equivalent core to Apple's A12 Vortex core but customers didn't want it? If yes, I strongly disagree. Even Intel and AMD are way behind Apple uarch in terms of IPC. Not mentioning relatively small ARM company. ARM hardly keeps up in terms of performance/watt ratio with much narrow/slow core.

I suggest that big cellphone cores and HPC/server cores will merge in near future, lets say about 5 years. We can see that x86 server cores in 64c EPYC are running 2.25 GHz base clock. Hypothetical server CPU based on Apple's Vortex cores could run at 2.5 GHz with much higher IPC and thanks to lower power consumption also with more cores. That's already happening with Nuvia IMHO. This is why Apple will swap to ARM instead of x86.

Developing wide power hungry core doesn't make sense if you meant this is Matterhorn. Max clocks are decreasing for power hungry x86 cores due to heat limitation, for phone cores are increasing because its low power design not being limited by heat but battery. It will meet at 3.5 GHz at 3nm/2nm finally. And later, phone cores will be able to have higher clocks than x86 cores due to ultra low power design in its genes. AMD and Intel will need to adapt and learn how to do that (AMD is already doing it, not sure if x86 can be as power efficient as ARM though). This is why Keller wanted to develop wide ARM core at AMD (he tried Nuvia thing 7 years ago, he is genius, at least he can see large picture IMHO). I'm just speculating and thinking loud. We'll see in future

 

[moinmoin]

and thanks to lower power consumption also with more cores. That's already happening with Nuvia IMHO.

Nuvia was only founded earlier this year and just had their first successful investment round, I don't think we will see a tangible product by them anytime soon.

Also in AMD's case the main power consumption already is in the uncore/IOD (a problem Nuvia and others will also face if they target i/o feature parity). The cores are already pretty efficient the way they are used in servers (negligible power usage at idle, boost frequency is right at the point above which efficiency decreases). AMD is bound to increase the core count further once die size allows (which I expect to happen with TSMC's 5nm).

 

[soresu]

Do you mean that ARM was able to design equivalent core to Apple's A12 Vortex core but customers didn't want it?

His point was that ARM does not design their big core for a single SoC vendor licensee but several - and going super wide would not necessarily be in their best interests due to the danger of alienating customers for whom it would not necessarily be needed, at least back when it went from concept to heavy design phase - which was at least as far back as 2015 or earlier, at which point WARM x86 app emulation was not yet known, or at least not widely known.

The announcement of WARM came the same year as the SoftBank acquisition, adn was likely the time at which they started to think wider.

For myself, I'm inclined to think that unless MS can do some ML augmented binary translation magic to get even close to native, then it won't matter how wide the core gets, it not only won't be enough - it will also shred the battery advantage that ARM is supposed to offer.

 

[soresu]

This is why Keller wanted to develop wide ARM core at AMD

He was hired by AMD to put them back on a competitive footing with Intel, his own desires had little to do with it.

He is still an employee doing a job at the end of the day - and the rest of the engineering team bare no small amount of responsibility for how well Zen turned out, even the greatest CPU architect is worthless without an extremely competent team to bring something as complex as a modern CPU uArch to fruition.

 

[insertcarehere]

Haven't been following the discussion with ARM Matterhorn, but am questioning the returns of continually making bigger core designs for ARM, even with HPC use in mind.

The garden variety A77 is already by all accounts as "wide" as Sunny Cove/Zen 2, give or take. HPC use cases should mostly be very well-threaded so beyond a baseline IPC, more cores should be a better solution than a bigger core, all things equal.

I reckon a better use of ARM's R&D resources would be to focus on making the core interconnects and memory system as good as possible, Retrofit the A77 with wider FP units if necessary, and pitch any resulting product as hard as possible to their clients to prove the viability of ARM in this segment.

Of course, with softbank writing the checks, ARM could do all those things AND work on Matterhorn if they really want to.

 

[soresu]

Found this on the main website about a 32C ARM Neoverse N1 chip being designed by AWS - though I would assume AWS to actually mean the same Alpine Labs that Amazon owns (whose chips are used in some NAS boxes).

Link here.

Also not ARM CPU news per se, but it's still ARM domain so it should go here.

It seems Imagination Tech is still punching high with a brand new uArch called A Series (A stands fro Albiorix).

Link here.

I didn't see references to RT capabilities oddly - considering their Wizard/Caustic Labs hardware I would have expect ed it. Perhaps to come later (unless I just missed it on my admittedly brisk scan through of the article).

 

[Richie Rich]

Thanks for news. It looks Amazon's CPU will do decent performance jump going from Cortex A72 to A76.

 

[DrMrLordX]

It isn't just A76 though. It's A76 that can do 3.1 GHz. Even the Snapdragon 855+ barely does 3 GHz . . . on one core!

 

[soresu]

Thanks for news. It looks Amazon's CPU will do decent performance jump going from Cortex A72 to A76.

It isn't just A76 though. It's A76 that can do 3.1 GHz. Even the Snapdragon 855+ barely does 3 GHz . . . on one core!

It's based on A76, but I think the extra 9 months before the N1 announcement was significant to the extra design of the 'uncore' elements involved - we still have no idea what kind of improvement these changes would bring, though there wouldn't be a direct comparison anyway I guess, given no A76 chip would get that big.

 

[Shivansps]

Playing around my RPI 4 i did discover that is not all about performance, x86 has a huge advantage in software development, and that is unaligned memory access, is so common in x86 world that CPUs are actually optimised for it. ARM is a big "NOPE", therefore software must be developed with memory aligment in mind, failing to do that that, the kernel can fix most of these cases at a performance cost, in other is just a big NO, SIGBUS.

And i know this because im trying to make a x86 game to work on ARM and the 3D models that the game loads are ifself unaligned, meaning the game runs into bad pointers when attepting to parse the info, SIGBUS.

So keep un mind that, its not only about general performance is not so easy to move from x86 to ARM, even if you can recompile software.

 

[soresu]

And i know this because im trying to make a x86 game to work on ARM and the 3D models that the game loads are ifself unaligned, meaning the game runs into bad pointers when attepting to parse the info, SIGBUS.

Not Freespace Open by any chance?

Given your user handle it seemed a safe bet.

 

[Shivansps]

Not Freespace Open by any chance?

Given your user handle it seemed a safe bet.

yep

 

[Thala]

Playing around my RPI 4 i did discover that is not all about performance, x86 has a huge advantage in software development, and that is unaligned memory access, is so common in x86 world that CPUs are actually optimised for it.

What a load of misinformation! While technically unaligned memory access is allowed for some instructions, it is ineffcient on any architecture even on x86. Therefore every compiler aligns memory access even on x86 architectures. Unaligned memory access is forbidden for any modern extensions like SSE, AVX etc. Intel would surely like to get rid of unaligned memory access if not for legacy compatibility reasons.
"Huge advantage in software development" ...

 

[Shivansps]

What a load of misinformation! While technically unaligned memory access is allowed for some instructions, it is ineffcient on any architecture even on x86. Therefore every compiler aligns memory access even on x86 architectures. Unaligned memory access is forbidden for any modern extensions like SSE, AVX etc. Intel would surely like to get rid of unaligned memory access if not for legacy compatibility reasons.
"Huge advantage in software development" ...

Fine, go and fix the all the software out there yourself then will talk. Im already have anger management issues trying to align the models files that the game loads so it will work on ARM. And no, unaligned access is a no-issue on x86. It may have been 20 years ago, but is not today.
And BTW, FSO uses AVX it works fine on X86, SIGBUS on ARM, and that is with kernel fixup enabled, whiout that is even worse.

 

[Richie Rich]

Huawei introduced desktop ATX motherboards for ARM CPUs!
ARM goes into desktop PC segment instead laptop one. That's interesting.

Huawei Aims for Desktop PC Market with Motherboard for Kunpeng 920 ARMv8 Processors

Huawei appears poised to enter the desktop PC market

www.tomshardware.com

Fine, go and fix the all the software out there yourself then will talk. Im already have anger management issues trying to align the models files that the game loads so it will work on ARM. And no, unaligned access is a no-issue on x86. It may have been 20 years ago, but is not today.
And BTW, FSO uses AVX it works fine on X86, SIGBUS on ARM, and that is with kernel fixup enabled, whiout that is even worse.

You are in wrong thread buddy.

 

[Thala]

Fine, go and fix the all the software out there yourself then will talk. Im already have anger management issues trying to align the models files that the game loads so it will work on ARM. And no, unaligned access is a no-issue on x86. It may have been 20 years ago, but is not today.
And BTW, FSO uses AVX it works fine on X86, SIGBUS on ARM, and that is with kernel fixup enabled, whiout that is even worse.

First of all i have compiled dozen of apps originally written for x86 to ARM without a single alignment issues. In the bigger picture such issues are virtually non existant. Second the alignment requirements of any modern compiler are the same for both ARM64 and x64. And as i said for SSE and AVX alignment is even enforced on HW level...e.g. you are getting an exception on unaligned access.
If you are having issues with a single project with a single external data structure, thats not even worth mentioning in this context. Besides what game are you talking about?
So stop this "Huge advantage in software development" - bullshit.

 

[Shivansps]

You are in wrong thread buddy.

In talking about issues trying to migrate a x86 program to ARM in
ARM Apple High-End CPU - Intel replacement

I think it is the right thread, we are talking about replacing x86 here.

First of all i have compiled dozen of apps originally written for x86 to ARM without a single alignment issues. In the bigger picture such issues are virtually non existant. Second the alignment requirements of any modern compiler are the same for both ARM64 and x64. And as i said for SSE and AVX alignment is even enforced on HW level...e.g. you are getting an exception on unaligned access.
If you are having issues with a single project with a single external data structure, thats not even worth mentioning in this context. Besides what game are you talking about?
So stop this "Huge advantage in software development" - bullshit.

If you are talking about in this context (replacing X86 with ARM) you cant ignore how software has been developed in all these years. Ive learned C/C++ 15 years ago and i never ran into this issue, i did not even know this was a issue. Just because YOU never had any problems dosen means that there are not going to be problems converting software from x86 to ARM with such a limitation in place.

I do agree, you are mostly going to run into this problem parsing files / external data, as compilers can fix most issues, but they do not fix all of them and certanly they cant fix what they do not know (like variable offsets). But programs with input/output files are very common and you cant say that. And i really cant belive that a modern ARM 8V-A A76 core cant deal with this... a Pentium MMX 133 dosent runs into this issue for god sake. In fact, the kernel is helping the ARM core A LOT.

 

[Thala]

In talking about issues trying to migrate a x86 program to ARM in
ARM Apple High-End CPU - Intel replacement

I think it is the right thread, we are talking about replacing x86 here.



If you are talking about in this context (replacing X86 with ARM) you cant ignore how software has been developed in all these years. Ive learned C/C++ 15 years ago and i never ran into this issue, i did not even know this was a issue. Just because YOU never had any problems dosen means that there are not going to be problems converting software from x86 to ARM with such a limitation in place.

Thing is, the evidence your are using is a single file parser in a single project. I am sure even in the very same project you are referring to, there are more file parsers, which work without any issues.

I do agree, you are mostly going to run into this problem parsing files / external data, as compilers can fix most issues, but they do not fix all of them and certanly they cant fix what they do not know (like variable offsets). But programs with input/output files are very common and you cant say that.

You are talking about a very rare issue when trying to port old software to newer architectures - and you generalize this into "huge advantage in software development".

And i really cant belive that a modern ARM 8V-A A76 core cant deal with this... a Pentium MMX 133 dosent runs into this issue for god sake. In fact, the kernel is helping the ARM core A LOT.

Did you know that ARMv7-A supports unaligned access? Even the lowest end Cortex-A5 supports unaligned access. They just scratched it with v8-A, because it is ineffcient, cost you transistors, performance and power and was considered a non-issue in the bigger picture. Do you know what the Intel architecture is doing with unaligned accesses? It splits them up into 2 aligned memory accesses. It is not a feature but a legacy burden of the x86/x64 architecture. Did you never ask yourself why a Skylake core is 3x larger than a Cortex A76 core with very similar performance per clock?
Regarding the Kernel is helping...on Windows for example there is just an exception thrown, which the user can handle or just fix the code. In the x86 emulator these things are handled of course. I am even surpised that some Linux Kernel have handlers for such behaviour.

 

[soresu]

Did you never ask yourself why a Skylake core is 3x larger than a Cortex A76 core with very similar performance per clock?

I always assumed CISC vs RISC was the answer.

SiFive claim to have a RISC V core half the size of A72 with same performance, and it would seem they pushed a purer RISC design with R5 than ARM v8-A.

 

[soresu]

Huawei introduced desktop ATX motherboards for ARM CPUs!
ARM goes into desktop PC segment instead laptop one. That's interesting.

Meh, still a soldered chip from the looks of it - no point going the desktop/tower path if you don't have the same versatility in DIY as the x86 space IMHO.

Though I'm sure the Linaro guy working on ARM desktops that Charbax talks to so much has wet himself in anticipation regardless.

 

[Nothingness]

Fine, go and fix the all the software out there yourself then will talk. Im already have anger management issues trying to align the models files that the game loads so it will work on ARM. And no, unaligned access is a no-issue on x86. It may have been 20 years ago, but is not today.
And BTW, FSO uses AVX it works fine on X86, SIGBUS on ARM, and that is with kernel fixup enabled, whiout that is even worse.

Sorry but it's been almost 15 years since unaligned accesses have been allowed on ARM CPU. So either your CPU is not properly configured or you didn't understand the issue you're facing.

BTW I get unaligned errors with AVX. Yeah. Really. Read Intel manuals.

 

[soresu]

Snapdragon 865 announced with A77 cores, strangely they seem to have dropped the Kryo branding, though I may have just misread something.

Link here.

2x the cache (512KB vs 256KB) on the prime A77 core as well as the higher clock.

 

[soresu]

Another news item, the open Adreno Vulkan driver TURNIP has just landed Compute Shaders and SSBO.

Not sure of the significance of the 2nd one, but obviously Compute Shaders are a big feature addition.

Link here.

 

[Richie Rich]

Snapdragon 865 announced with A77 cores, strangely they seem to have dropped the Kryo branding, though I may have just misread something.

Link here.

2x the cache (512KB vs 256KB) on the prime A77 core as well as the higher clock.

They dropped Kryo branding because they use original A77 Cortex core (no custom core tweaks).

 

[Shivansps]

Sorry but it's been almost 15 years since unaligned accesses have been allowed on ARM CPU. So either your CPU is not properly configured or you didn't understand the issue you're facing.

BTW I get unaligned errors with AVX. Yeah. Really. Read Intel manuals.

You are telling me, that SEGBUS is not an aligned memory access error even trought im telling im fixing it by aligning the data the program parses? This is with kernel fixup enabled, so that is already helping.

You are more than welcome to take and look

[3.7.2-ARM] Unaligned Memory Access at modeloctant.cpp:28 (title edited)

[3.7.2-ARM] Unaligned Memory Access at modeloctant.cpp:28 (title edited)

www.hard-light.net

But it is unaligned memory access, no way around it. Thats why im writting a tool to fix the 3D models so the game can run on ARM cpus.

All i can say i have a renewed love for x86 after this experience. ive never written any AVX code and i have no experience with AVX.