Arch Linux CachyOS Benchmarks Of x86-64-v3 & x86-64-v4 Repositories

[sobrus]

Even generic x64 build has SSE and SSE2 optimizations always enabled. These are quite powerful on their own. And code highly benefiting from AVX or longer vector sizes in general, is usually optimized already.
But it's good to see that there are still some cases when any AVX is clearly superior when recompiled.

The CachyOS repos can be as well used for "pure". We extra have arch only packages in "cachyos-core-v3", "cachyos-extra-v3" and same for v4. There are not any PKGBUILDs changed and an plain rebuild.
In cachyos-v3 and cachyos-v4 are some customized packages to enable PGO and other optimization/changes on these.

Thank you for explanation! I have one more question, some packages are marked as x86-64-v3 architecture, other as generic x86-64. But these are v3 as well (I've actually tried to run v3 package on v2 cpu to confirm that lol). Why two different package designations?

[V1tol]

I am not sure this benchmark is very representative since it compares CachyOS variants only. IIRC CachyOS does optimized package builds even for non-v3-v4 repo packages. It would be interesting to bench stock Arch vs CachyOSed/ALHPied installation.

[sophisticles]

Many years ago, on another forum, I floated the idea that Linux distros should be compiled with SSE optimizations enabled, or even better, have the whole thing coded from top to bottom to use SSE.

There were many that said it sounded like a great idea wondered why it wasn't being done.

Eventually i realized why it was a bad idea.

There are a limited number of SIMD units on a processor, SIMD units allow a single instruction to work on multiple pieces of data, but if you have multiple programs trying to do this at the same time, you quickly saturate the SIMD units and kill any performance gains that you would otherwise gain.

SIMD use is only beneficial when it is used sparingly, technically you could code an entire program to run on the SIMD units but you would not see any performance fain, in fact you may see a slow down.

It is best to compile the distro and applications with generic options and let the code the developers wrote do its thing.

If using compiler optimizations greatly improves performance of an application then that is a sign that the developers did not optimize their code and you should consider using software coded by people that know what they are doing.

[dayone]

Would be nice to see comparisons with other Distros and maybe some Gaming Benchmarks.

[Michael]

Unfortunately this particular review unit system (HP Z6 G5 A) since had to be sent back so if any follow-up / related tests will need to start over from scratch on all the testing.

[ptr1337]

Even generic x64 build has SSE and SSE2 optimizations always enabled. These are quite powerful on their own. And code highly benefiting from AVX or longer vector sizes in general, is usually optimized already.
But it's good to see that there are still some cases when any AVX is clearly superior when recompiled.



Thank you for explanation! I have one more question, some packages are marked as x86-64-v3 architecture, other as generic x86-64. But these are v3 as well (I've actually tried to run v3 package on v2 cpu to confirm that lol). Why two different package designations?

Yes, we packages which build customized build (in docker container) providing the CARCH=x86_64_v3/_v4 from the packagearch.

We have a pacman patch, which additionally detects the supported CARCH by the user, equal detection as "rpm" has. (Patch got rejected by upstream arch, since "everyone can set their own Architecture in the pacman.conf, instead of relaying to auto detection"). This is an additional layer of protection, if the "cachyos-v4" and "cachyos-v3" repository is used.

We will plan in the future, to build all other packages with the correct "CARCH", but currently some PKGBUILDs relay on the CARCH, which would lead into problems.
devtools has integrated some kind of "set alias" to mitigate these issues, but we havent integrated them into our automatic cachybuilder, yet.

We have an alternative solution with pacman, which overrides the compiled CARCH automatically, but this does currently do problems when used with AUR helpers.
Anyways - you can be sure that packages in the corresponding repository are build with the Architecture end (-v3 , -v4).

[ptr1337]

I am not sure this benchmark is very representative since it compares CachyOS variants only. IIRC CachyOS does optimized package builds even for non-v3-v4 repo packages. It would be interesting to bench stock Arch vs CachyOSed/ALHPied installation.

Currently following arch packages are optimized in v1:
- lz4 (PGO)
- zstd (PGO)
- xz (PGO)
- ripgrep (PGO)
- julia (PGO)
- python (BOLT)

Besides these its stock archlinux.

[Vortex Acherontic]

Would be interesting to see Tumbleweed with v3 packages vs CatchyOS with v3 packages

[avis]

v3/v4 advantage over plain x86-64 is not so clear cut. There are far too many regressions and it looks like it would be best if it were per application/library, not for everything.

[Draget]

Hey, may I interest you in something called 'Gentoo'…