Discussion ARM Cortex/Neoverse IP + SoCs (no custom cores) Discussion

naukkis · Feb 15, 2025

Nothingness said:
I think we already went through this. I'd really like to see code VL agnostic and make comparisons of SVE vs R-V vector extension.

I've seen VL agnostic SVE code that doesn't need a single change for different VL. But I guess there are cases where that doesn't work (shuffles?) and I'd be interested in seeing how R-V handles that.

Vector ISA is hardware abstraction layer. By definition everything just works - and it's not only theoretical as working vector cpus have been build from 70's. Every op is scalar - SIMD packing is only done in hardware level which doesn't show outside. (there might be side-channels though). SVE other hand have some instructions scalable with hardware tail handling and part of instructions needs different software handlers for different SIMD widths. It seems to be nightmare beyond any other commercial architechture. Waiting to see when some hardware maker finally implements SVE over 128 bits, offers Linux support and Linus Torvalds tries to implement and verify algorithms to support it. I might be totally wrong and SVE is actually fine to code for - but as years go and nobody bothers to use it I suspect that everybody else is also seeing SVE problems and stay as far as possible from it.

LightningDust · Feb 15, 2025

LightningDust's axioms:

1. Any thread containing naukkis will inevitably degenerate into naukkis insisting that anything but length-abstracted vector machines is doomed and obsolete.
2. Any thread containing LD will inevitably degenerate into LD insisting* that EPIC was Good Actually

* correctly

Nothingness · Feb 16, 2025

naukkis said:
Waiting to see when some hardware maker finally implements SVE over 128 bits, offers Linux support and Linus Torvalds tries to implement and verify algorithms to support it. I might be totally wrong and SVE is actually fine to code for - but as years go and nobody bothers to use it I suspect that everybody else is also seeing SVE problems and stay as far as possible from it.

As far as Arm goes:
- First Neoverse were 256-bit
- Fujitsu is 512-bit
- Apple M4 supports 512-bit in streaming SVE (though it's too slow to be really worth it in general)
- You can buy boards with 128-bit CPU
- SVE implementations exist in open source software (including support in Linux kernel)
- gcc/clang can generate VL agnostic SVE code.

I'll leave it to you to list the existing R-V vector implementations and what software makes use of it.

For the rest of your message you seem to think SVE can only handle multiple of VL flows of data. That's wrong. Predicates and fault ignoring in loads allow to change that. I'll agree that VL can't exceed the hardware width of SVE registers (currently 128, 256 or 512 depending on CPU). But a 512-bit implementation will happily run software for 128 or 256-bit vectors without changing a line of code for many vectorized loops.

Nothingness · Feb 16, 2025

LightningDust said:
LightningDust's axioms:

1. Any thread containing naukkis will inevitably degenerate into naukkis insisting that anything but length-abstracted vector machines is doomed and obsolete.

Which makes me wonder: is anyone still doing "clean and pure" vector CPUs? I mean except R-V vendors who are stuck in 20th century (apologies for the obvious trolling).

2. Any thread containing LD will inevitably degenerate into LD insisting* that EPIC was Good Actually

* correctly

Code:

s/LD/SK/g

LightningDust · Feb 16, 2025

Nothingness said:
Which makes me wonder: is anyone still doing "clean and pure" vector CPUs? I mean except R-V vendors who are stuck in 20th century (apologies for the obvious trolling).

NEC, though they're exiting that market. Was always really about domestic-market seismic-analysis and weather codes that are hypersensitive to memory-bandwidth and have basically arbitrary amounts of DLP.

Nothingness said:
Code:

s/LD/SK/g

I could not possibly be the Queen of Blades. She got dragged into way too many idiot arguments about "x86 good in sekrit ways that don't show up on benchmarks." I'm just here for EPIC apologia. Important difference!

MS_AT · Feb 16, 2025

naukkis said:
but as years go and nobody bothers to use it

Have you checked if it is not being used in server deployments? Fujitsu for one will be using that. On mobile it is not suprising nobody is using it since everything still supports Neon. Why support 2 code codebases (since budget devices won't support SVE still for some time) when one (Neon) will cover everything Android?

camel-cdr · Feb 16, 2025

MS_AT said:
Why support 2 code codebases (since budget devices won't support SVE still for some time) when one (Neon) will cover everything Android?

It's worse than that, apart from the a64fx every SVE implementation reuses the NEON ALUs for their SVE implementation AFAIK.
So on the Neoverse V1, you can use four issue 128-bit NEON or two issue 256-bit SVE.
Which makes the gain from SVE minimal.

Doug S · Feb 16, 2025

LightningDust said:
* correctly

Citation needed.

LightningDust · Feb 16, 2025

Doug S said:
Citation needed.

When IPF was invested in, performance was generally good to excellent, despite Montecito being delayed, Hondo being an abomination built out of PA-8800 bits, etc. (Merced is safely ignored, as it bears no resemblance to any other Itanium microarchitecture, but even it put up respectable SPEC numbers.)

IPF's reputational issues were always a matter of expectations - "64-bit evolution of x86", "industry-standard 64-bit merchant processor", and that stupid IDC projected-volume graph - rather than what the Fort Collins design group actually delivered, which was generally pretty decent.

Doug S · Feb 17, 2025

LightningDust said:
When IPF was invested in, performance was generally good to excellent, despite Montecito being delayed, Hondo being an abomination built out of PA-8800 bits, etc. (Merced is safely ignored, as it bears no resemblance to any other Itanium microarchitecture, but even it put up respectable SPEC numbers.)

IPF's reputational issues were always a matter of expectations - "64-bit evolution of x86", "industry-standard 64-bit merchant processor", and that stupid IDC projected-volume graph - rather than what the Fort Collins design group actually delivered, which was generally pretty decent.

Performance was always well behind x86. Itanium failed because the whole idea that a magic compiler will find more ILP than a CPU can at runtime was massively flawed.

If you want to imply lack of investment did it in, what about the lack of investment in Alpha? If you devoted equal resources to both IPF would have looked silly by comparison. The lack of investment was because its design roadmap showed it couldn't compete with x86, especially not after x86 went 64 bits (despite Intel doing everything they could to avoid or at least delay that and prop up Itanium) and gained some breathing room on registers and no longer needed any kludges to handle more than 2 GB.

Itanium was done in like the RISCs it (briefly) replaced, because a market niche can't compete with x86 so the latter got more investment and cheaper pricing. The same massive revenue advantage in Apple's ARM products (iPhone/iPad) was used to dethrone x86 and kick it out of the Mac.

igor_kavinski · Feb 17, 2025

Intel is no stranger to shooting itself in its own feet, both of them. They destroyed the performance potential of AVX-512 by not releasing it in all their consumer CPUs (yes, even Celerons should've had them, if just a cut-down version).

Similarly, they tried being greedy and sell a 64-bit CPU to corporations hoping they would somehow destroy IBM overnight and take control of the entire world with their 64-bit revolution when a simple mass market consumer CPU line-up with IPF architecture could've generated developer interest, ensured tons of open source development and eventual success within a decade.

Heck, they could've put an Atom CPU alongside that IPF based CPU to provide backward compatibility. But simple solutions don't appeal to the morons deciding Intel's fate.

Nothingness · Feb 17, 2025

igor_kavinski said:
Heck, they could've put an Atom CPU alongside that IPF based CPU to provide backward compatibility. But simple solutions don't appeal to the morons deciding Intel's fate.

For some reason I thought the first Itanium had an x86 core in them, but I can't find any reference to that. Failing memory likely.

adroc_thurston · Feb 17, 2025

Nothingness said:
For some reason I thought the first Itanium had an x86 core in them, but I can't find any reference to that. Failing memory likely.

There were plans to, but in the end it used slowass software emulation.

LightningDust · Feb 17, 2025

Doug S said:
Performance was always well behind x86

SPEC disagrees. So do a bunch of real applications I've worked with.

Doug S said:
Itanium failed because the whole idea that a magic compiler will find more ILP than a CPU can at runtime was massively flawed.

If you want to imply lack of investment did it in, what about the lack of investment in Alpha? If you devoted equal resources to both IPF would have looked silly by comparison.

Shrug. The HP userbase was bigger, so their needs won. The Compaq kids got a VMS port as a consolation prize.

Doug S said:
Itanium was done in like the RISCs it (briefly) replaced, because a market niche can't compete with x86 so the latter got more investment and cheaper pricing. The same massive revenue advantage in Apple's ARM products (iPhone/iPad) was used to dethrone x86 and kick it out of the Mac.

Yep. Power's still slouching along, but it isn't particularly performance-competitive with x86 anymore - especially for the price. Certainly I don't remember saying that RISC/UNIX was long-term commercially viable.

adroc_thurston said:
There were plans to, but in the end it used slowass software emulation.

On the contrary, three generations of Itanium had a hardware x86 block, an alternate frontend rather than a full x86 core (Merced, McKinley, and Madison.) It was very bad. IA-32 EL, the software emulator that came in after around 2004, was actually pretty good (perf comparable to a similarly-clocked Prescott, so not amazing, but acceptable for running Windows utility software, which was the main use case.)

igor_kavinski said:
Heck, they could've put an Atom CPU alongside that IPF based CPU to provide backward compatibility.

In 2001?

igor_kavinski · Feb 17, 2025

LightningDust said:
In 2001?

Didn't realize that the Atom was a later design. Oh well. Maybe a tiny Tualatin Celeron could've worked instead, running at 400 MHz.

LightningDust · Feb 17, 2025

LightningDust said:
SPEC disagrees. So do a bunch of real applications I've worked with.

Elaborating on this, I bring to you three pairs of processor results for spec06. All but one (Woodcrest SPECFP) are non-autoparallel to try to level the playing field.

Opteron 2222 (3GHz second-gen K8, 90nm):

14.7/16.1 int
14.8/16.0 FP

CINT2006 Result: Hewlett-Packard Company ProLiant DL185 G5 (3.0 GHz AMD Opteron 2222)

CINT2006 result for ProLiant DL185 G5 (3.0 GHz AMD Opteron 2222); base: 14.7; peak: 16.1

spec.org

CFP2006 Result: Hewlett-Packard Company ProLiant DL185 G5 (3.0 GHz AMD Opteron 2222)

CFP2006 result for ProLiant DL185 G5 (3.0 GHz AMD Opteron 2222); base: 14.8; peak: 16.0

spec.org

Xeon 5160 (3GHz Woodcrest, 65nm):

18.7/20.4 int
16.6/17.2 FP

CINT2006 Result: NEC Corporation Express5800/120Li (Intel Xeon processor 5160)

CINT2006 result for Express5800/120Li (Intel Xeon processor 5160); base: 18.7; peak: 20.6

spec.org

https://spec.org/cpu2006/results/res2007q4/cpu2006-20071109-02479.html (autopar)

Itanium 9140 (1.66GHz Montvale, 90nm):

15.7/17.0 int
19.9/20.4 FP

CINT2006 Result: Hewlett-Packard Company HP Integrity rx2660 (1.66GHz/18MB Dual-Core Intel Itanium)

CINT2006 result for HP Integrity rx2660 (1.66GHz/18MB Dual-Core Intel Itanium); base: 15.7; peak: 17.0

spec.org

CFP2006 Result: Hewlett-Packard Company HP Integrity rx2660 (1.66GHz/18MB Dual-Core Intel Itanium)

CFP2006 result for HP Integrity rx2660 (1.66GHz/18MB Dual-Core Intel Itanium); base: 19.9; peak: 20.4

spec.org

I would call that competitive. Not dominant, but competitive. Bearing in mind that the Woodcrest has a full lithography generation advantage, that Montecito/Montvale are using a reheated version of a microarchitecture that was at that point five years old, and that Montecito/Montvale lost 10-15% of their originally announced clock speed due to the late-breaking Foxton erratum, I don't consider that to be a particularly poor showing for the EPIC concept.

soresu · Feb 17, 2025

igor_kavinski said:
Intel is no stranger to shooting itself in its own feet, both of them. They destroyed the performance potential of AVX-512 by not releasing it in all their consumer CPUs (yes, even Celerons should've had them, if just a cut-down version).

IMHO this was a relic of the time when they had little/no competition from AMD and were just seeking to monetise their IP down to the dregs, even to the point of segmenting the high end and server ISA feature sets from that of the mainstream and value SKUs.

Not that I am saying it's AMD's fault - only that the lack of competition simply gave them the breathing room to be what Intel always has been.

soresu · Feb 18, 2025

camel-cdr said:
It's worse than that, apart from the a64fx every SVE implementation reuses the NEON ALUs for their SVE implementation AFAIK.
So on the Neoverse V1, you can use four issue 128-bit NEON or two issue 256-bit SVE.
Which makes the gain from SVE minimal.

This is unlikely to change for any v9.x-A based CPU as NEON is mandatory.

That being said, I suspect that new NEON instructions have been few and far between since SVE2 was announced, and the delta in instruction parity is only going to widen as successive increments of SVE2 become available.

v9.6-A already came with SVE2p2, its 2nd extension.

adroc_thurston · Feb 18, 2025

camel-cdr said:
Which makes the gain from SVE minimal

It's an ISA that doesn't make you want to gouge own eyes out for one.
It's still eh though.

soresu · Feb 18, 2025

Oh huh, look what I found when trawling the ARM developer documentation:

+sve2p1

Extends +sve2 to support a number of instructions that have been moved from SME, and includes changes to Streaming SVE mode instructions in SVE2.1 (FEAT_SVE2p1).

I wonder what this augurs for the future of SME/SME2 in ARM Ltd's own CPU µArchs.

naukkis · Feb 22, 2025

LightningDust said:
LightningDust's axioms:

1. Any thread containing naukkis will inevitably degenerate into naukkis insisting that anything but length-abstracted vector machines is doomed and obsolete.

It's about vector length agnostic designs - there is full vector isa implementations and ARM SVE, scalable packed SIMD arch. And ARM SVE doesn't actually work because vector register manipulation instructions aren't vector length agnostic but need software support for every supported vector length. And by definition SVE supports every vector length between 128 and 2048 bits with 128 bit intervals. OK they backed up later revisions to only support 2-base vector lengths but still - that design in unusable as vector length agnostic. Arm did try but after 10 years and practically zero support for both software and hardware makers I think they should seriously reconsider to set SVE as fixed length design for maybe 128,256 and 512 bit vectors like AVX512 to get actually usable platform which developers could actually adopt without seeing nightmares from supporting something that is fundamentally broken.

Doug S · Feb 23, 2025

soresu said:
Oh huh, look what I found when trawling the ARM developer documentation:

+sve2p1 Extends +sve2 to support a number of instructions that have been moved from SME, and includes changes to Streaming SVE mode instructions in SVE2.1 (FEAT_SVE2p1).

I wonder what this augurs for the future of SME/SME2 in ARM Ltd's own CPU µArchs.

I wonder if those changes to SSVE were driven by Apple, to work around the issues that caused them to mostly ignore SSVE in M4/A18 as far as performance goes. Maynard can speak to this better since he suggested a few changes that would make the way Apple wants to do things work much better - and presumably get them to start caring about SSVE performance in future designs.

naukkis · Feb 25, 2025

Doug S said:
I wonder if those changes to SSVE were driven by Apple, to work around the issues that caused them to mostly ignore SSVE in M4/A18 as far as performance goes. Maynard can speak to this better since he suggested a few changes that would make the way Apple wants to do things work much better - and presumably get them to start caring about SSVE performance in future designs.

What Apple did - they took those vector length agnostic parts from SVE, added few outer matrix registers for better supporting matrix math and build very simple mostly in-order VPU around it. For general purpose performance they need those vector register manipulation instructions which ARM lacks - or implement strong OOO capabilities - which pretty much nullifies whole idea of power-efficiency optimized vector math unit. So I think that Apple doesn't target general purpose SSVE performance anytime soon on their designs.

Nothingness · Feb 25, 2025

naukkis said:
For general purpose performance they need those vector register manipulation instructions which ARM lacks

What do you mean? All of what Apple implemented in their SME unit was fully architected by Arm and has been documented even before M4 release.

naukkis · Feb 25, 2025

Nothingness said:
What do you mean? All of what Apple implemented in their SME unit was fully architected by Arm and has been documented even before M4 release.

It is Apple design - firstly known as AMX. Arm implemented it later to their instruction set. It's a subset of SVE - you know your instruction set is great when customers don't want to implement it fully.

Discussion ARM Cortex/Neoverse IP + SoCs (no custom cores) Discussion

Senior member

Member

Diamond Member

Diamond Member

Member

Senior member

Member

Diamond Member

Member

Diamond Member

Lifer

Diamond Member

Diamond Member

Member

Lifer

Member

Diamond Member

Diamond Member

Diamond Member

Diamond Member

Senior member

Diamond Member

Senior member

Diamond Member

Senior member