Martin Jambor
Hello,
On Fri, Aug 05 2022, Dan Čermák wrote:
dieter
writes: Hi,
On Thu, 04 Aug 2022 18:40:23 +0200 Martin Jambor wrote:
Are there some data available about the actual benefit of this change?
Over the weekend, I have quickly gathered some SPEC CPU benchmarks results comparing the different x86_64 versions:
thanks, very interesting results. I admit this gain is even less than I expected.
Yes, the gain is small, but a few percent gain will result in e.g. HPC users to pick another distribution. But yeah, the gain in these benchmarks is really surprisingly small.
please note that I measured SPEC only because I already have the setup to run it quickly and then compare the results. The results show some benefits, for example the improvements in 531.deepsjeng_r is most likely because of POPCNT and the software you use may contain more such opportunities to utilize these "new" instructions. And I do think that at some point old HW just should not be considered a blocker to progress - and more than a decade seems like old to me.
But while I am myself somewhat undecided about switching to -v2, I would like the openSUSE community to look at the -v3 improvements too, because the floating-point ones are IMHO big. ImageMagick alone runs 20% faster and that means that compiling for older HW wastes a lot of compute power (and thus a lot of energy too) on new machines.
Can we estimate when we will want to switch to -v3? (I assume we don't want to do it now.) In two years? Four years? Six years? Never?
I think that arriving at some consensus would benefit not just planners at both openSUSE and SUSE but also users still relying on machines that do not support -v3 (I regularly use one too and also would like to keep it for a few more years :-).
I will object to switching to x86_64 v3 as the only option in the
foreseeable future (at least for the next decade), because this baseline
just got introduced and people will still be using perfectly working
machines whom we would cutoff. I consider this a disservice to our users
given that this is a *technical* problem that should be fixed.
Cheers,
Dan
--
Dan Čermák