On Wed, Aug 10, 2022 at 06:33:29PM +0200, Martin Jambor wrote:
Hello,
On Wed, Aug 10 2022, Dan Čermák wrote:
Martin Jambor <mjambor@suse.cz> writes:
Hello,
On Fri, Aug 05 2022, Dan Čermák wrote:
dieter <d_werner@gmx.net> 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.
I'll be happy if I am proven wrong but I disagree that this is a "problem" that can be "fixed" into non-existence (except if we provide both -v1 and -v3).
Rather than a problem - technical or otherwise - we are facing a trade-off that is inherent in the nature of the situation. Either we do a "disservice" to users of old machines because their n years (and ticking) old machines will stop working or we do a "disservice" to users of new machines who have workloads which run slower.
I would like to see this 'disservice' to users of newer hardware somehow clarified. From the benchmarks AFAICT v2 is not even overall gain, and while v3 is very slightly better I doubt it would be noticable for, say, a desktop. HPC is not real reason either because 1) it's moving towards using GPUs anyway 2) if you still do calculations on CPU you are likely going to use specialized libraries that have dynamic CPU detection, anyway Finally if you want to squeeze last fraction of a percent of performance out of your CPU you will have to taylor the compiler options to your particular CPU, and do your own bemchmarking - the prebuilt binaries are not really heplfule for that. And there is OBS for packaging your own. I have not heard about a specific case where not having some more recent instructions brings in complex code patching, extra maintenance, or any such problem. In any case if such use case does exist I would like to hear which specific CPU feature enables the optimization, not some random bag of unrelated CPU features called x86_64-vn.
The answer may well be that even in 2030 it will be more important that machines from 2018 work but we should acknowledge that we have decided to impose the price on a different set of our users.
If we cannot point out any noticeable price the users of newer CPUs are actually paying for the old CPU support then we shoud keep the support even in 2030 I suppose. Although I have my doubts about that - CPU obsolescence generally happens in generations by some developments that render the CPU generation practically insufficient in some way, and while the Core(2) CPUs are usable today they are nearing their practical usability EOL.
Alternatively openSUSE can somehow cough up the resources to provide an additional distribution flavor - where it will bear the hardware and electricity cost of the trade-off. Or we can decide that having multiple x86_64 flavors is more important than having a 32bit version and stop building i686, which would be a disservice to all the happy users of that. Another trade-off.
The trade-off can be made smaller and indeed is by many projects dynamically dispatching into routines specialized for a given ISA version or even specific CPU. For many users this can cover all of their interesting workload, for example if their only use for AVX2 is video codecs.
But that is not the case for all. Real ImageMagick is probably a good example but I have not checked thoroughly. Implementing dynamic dispatching in projects which don't have it basically requires that upstream authors of the projects do it and it may often be a lot of work and quite some complexity to be dealt with forever.
I appreciate that ImageMagick execution speed is a nice compiler benchmark but I have to ask how many people run ImageMagick all day. Sure, there are some web services that might use it for image processing but I have no idea how many are out there. I vaguely remember some specialized C++ image processing libraries for image recognition but I also remember that I had to build them myself, anyway. Thanks Michal