Ampere Altra Performance Shows It Can Compete With - Or Even Outperform - AMD EPYC & Intel Xeon

[coder]

It seems unlikely that the numbers are swapped given it's all automated. Since 2 reputable sites report very different results for the same benchmark it is more likely there is a difference in the setup. Phoronix didn't use the CentOS install like the others. Since that came installed, it is likely better tuned, but the difference is way too large even considering the 4 vs 64KB pages.

I agree with schmide -- in spite of any distro differences, LLVM 10 vs. 11, or SSD vs. ramdisk, it's just hard to see how 112 Xeon threads are faster than 160 N1 cores by a whopping 23%! That's a per-thread advantage of 76%, for the Xeon!

I guess if there were some weird thread scheduling bug, that would also explain why Altra is also using so much less power, when the other power plots show it very much in the same ballpark as the Xeon-based machine.

[schmide]

I agree with schmide(snip)
guess if there were some weird thread scheduling bug, that would also explain why Altra is also using so much less power, when the other power plots show it very much in the same ballpark as the Xeon-based machine.

From serverthehome review

Ubuntu gave us a bit of a challenge due to the fact that the server would not hit turbo frequencies with the standard installation. This simply required using:

echo 1 > /sys/devices/system/cpu/cpufreq/boost

arm should be very good at compiling

[coder]

It means that compilers generate code that runs well on modern x86 cores. They avoid complex instructions that tend to be slow and prefer fast instructions and addressing modes. Even in the base x86-64 mode heuristics (inlining, unrolling, etc) have been fine tuned for modern x86 cores.

You're either forgetting or ignoring what we learned with:

https://www.phoronix.com/scan.php?page=article&item=amd-znver3-gcc11

It shows a wide diversity among even fairly recent x86 CPUs, and that the baseline x86-64 target is not very optimal for newer cores.

Almost all GCC developers work on x86, so every new feature, change or optimization has been tuned for x86, not for AArch64. As a result AArch64 is not just at a disadvantage but often losing performance due to these changes. Recent GCCs do indeed generate reasonable code for AArch64 because Arm has invested into open source compilers. But with 90% of developers optimizing for x86 it's not nearly as tuned as x86.

These are just faerie stories. Even the most far-fetched conspiracy theories have a greater body of evidence than you've provided.

And while most open source packages support AArch64 today, they are almost exclusively being optimized and tuned for x86.

Again, claims without data. I can refute it in kind. I've seen lots of packages with ARM optimizations, because it turns out that the software ecosystem of phones isn't that different from a desktop PC. This and desire to improve performance and energy-efficiency has provided plenty of incentive for ARM optimizations in a wide variety of software tools and packages. Sure, there will be some exceptions, but you've yet to show how ARMv8-A cores are materially disadvantaged in any of the benchmarks included here.

A major issue is that AArch64 systems are not easily available to developers - a mobile phone or PI doesn't make a good developer box!

I'd have agreed with you on the Pi, until about v3. Certainly, v4 is usable as a desktop. Of course, there's also cloud hosting.

[coder]

Ubuntu gave us a bit of a challenge due to the fact that the server would not hit turbo frequencies with the standard installation.

In anandtech's coverage, they went into some depth on clock frequencies, and how Ampere seems to be making a big deal about deterministic performance and how it basically holds the max frequency indefinitely. They claimed that it basically only dropped the frequency so it could idle at lower power. So, I guess... what turbo?

https://www.anandtech.com/show/16315...altra-review/2

And you certainly wouldn't expect turbo to be a big factor in a benchmark like LLVM compilation, with all of that concurrency.

arm should be very good at compiling

Agreed.

[tuxd3v]

Yes x64 is very old, and that means that compilers and software have been optimized for it. AArch64 is newer and thus less mature. And Zlib was optimized for SSE2 many years ago.

X64 is the intel implementation of 64 bits not in use anymore..at least for some 14-15 years now..
amd64 won the contest!

Yes compilers are mature, but software still needs to be pushed up to take advantage of the base amd64 features..
ARM64 because its newer, packages are built from the ground up with support for most common things in arm64, that's the difference..

[coder]

X64 is the intel implementation of 64 bits not in use anymore..at least for some 14-15 years now..
amd64 won the contest!

You're probably thinking of IA-64. Intel has been releasing new IA-64 CPUs until just a few years ago, but you're right that the writing has been on the wall for about that long.

https://en.wikipedia.org/wiki/IA-64

Yes compilers are mature, but software still needs to be pushed up to take advantage of the base amd64 features..

Huh? Care to cite any specifics or examples?

The biggest issue with x86-64 (AKA AMD64) is that it's like 15 years old and much has been added since. That's why there's been a push to establish a more modern baseline:

https://www.phoronix.com/scan.php?pa...Feature-Levels

[PerformanceExpert]

X64 is the intel implementation of 64 bits not in use anymore..at least for some 14-15 years now..
amd64 won the contest!

Yes compilers are mature, but software still needs to be pushed up to take advantage of the base amd64 features..
ARM64 because its newer, packages are built from the ground up with support for most common things in arm64, that's the difference..

You know x64, x86-64 and AMD64 are used as synonyms? All the base features are used when building packages in a distro. In cases where an extension gives a large benefit people add optimized code paths to that package. This applies to Arm as well since many features are optional. Eg. the CRC calculation in DPDK needs runtime checks before using PMULL instructions on AArch64.

[PerformanceExpert]

You're either forgetting or ignoring what we learned with:

https://www.phoronix.com/scan.php?page=article&item=amd-znver3-gcc11

It shows a wide diversity among even fairly recent x86 CPUs, and that the baseline x86-64 target is not very optimal for newer cores.

You still haven't shown how this is relevant for this set of benchmarks. It's incredible how people on here seem to think that a result for one set of benchmarks applies to a completely different set of benchmarks. Do you also believe that ClearLinux will speed this set of benchmarks up by exactly 15%???

These are just faerie stories. Even the most far-fetched conspiracy theories have a greater body of evidence than you've provided.

I can tell you have never done any serious software development. If you don't get developers' mindshare you don't go anywhere. It's why I believe RISC-V is going nowhere.

Again, claims without data. I can refute it in kind. I've seen lots of packages with ARM optimizations, because it turns out that the software ecosystem of phones isn't that different from a desktop PC. This and desire to improve performance and energy-efficiency has provided plenty of incentive for ARM optimizations in a wide variety of software tools and packages. Sure, there will be some exceptions, but you've yet to show how ARMv8-A cores are materially disadvantaged in any of the benchmarks included here.

Sure some important packages been optimized, but there is a huge amount of optimization and tuning left to be done. Note also such optimizations were mostly done for older microarchitectures, and they are not optimal on newer cores (eg. DPDK has an optimized CRC check, however it would be twice as fast if tuned for Neoverse N1). I already mentioned one disadvantage that will affect almost all benchmarks: 4KB pages instead of the default 64KB pages.

I'd have agreed with you on the Pi, until about v3. Certainly, v4 is usable as a desktop. Of course, there's also cloud hosting.

LOL. A quad A72 at 1.5GHz is equivalent to one N1 core... Try bootstrapping GCC on it and let me know how it went. It's not meant for developers. The 16-core LX2 boards are much faster, so ok for development. However they are still not ideal for optimization given A72 is ancient. With Graviton 2 there is finally a cheap option for doing development and optimization for the latest microarchitectures.

[tuxd3v]

You're probably thinking of IA-64. Intel has been releasing new IA-64 CPUs until just a few years ago, but you're right that the writing has been on the wall for about that long.

IA-64 was for the Itanium cpus( or the HP CPUs, because it was HP that developed them intel come later in the process, and ended buying all the Itanium stuff. ).

https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing

X64 was the intel attempt to compete with amd64( some ~15 years ago ), but amd64 won( also because at the time Microsoft had already a port of its OS to amd64 and refused to create another one for intel X64 ).

The biggest issue with x86-64 (AKA AMD64) is that it's like 15 years old and much has been added since. That's why there's been a push to establish a more modern baseline:

Well I agree that a lot have changed indeed,
In my perspective, if you release a amd64 distro, it should that advantage of what amd64 baseline provides..
The baseline is very well known for amd64, that should be the base for any amd64 distro..

I am also in favour that i386 should be bumped to i686 baseline..

[PerformanceExpert]

X64 was the intel attempt to compete with amd64( some ~15 years ago ), but amd64 won( also because at the time Microsoft had already a port of its OS to amd64 and refused to create another one for intel X64 ).

Intel's variant was never made public, and very little is known about it, so we always mean x86_64 when we talk about x64.

Well I agree that a lot have changed indeed,
In my perspective, if you release a amd64 distro, it should that advantage of what amd64 baseline provides..
The baseline is very well known for amd64, that should be the base for any amd64 distro..

I am also in favour that i386 should be bumped to i686 baseline..

That's exactly what distros do - the baseline includes SSE2 for 64-bit of course. The baseline for 32-bit code has been i686 for many years. The only oddity is that GCC still uses slow x87 eventhough the baseline includes SSE2. x87 is the worst ever FP ISA designed (totally incompatible with IEEE754) and should really die - but then again who still uses 32-bit code?