On Wed, 31 Jul 2019 at 09:15, Frantisek Zatloukal <fzatlouk(a)redhat.com>
Personally, I am not at all against raising the bar for baseline
Of course, it'd be ideal to have some sort of derived x86_64_avx arch, but
if we find out it'd require too much of an investment into infra/releng,
I'd be +1 for just changing the base x86_64. Sure, it'd make sense to
actually see some numbers from Fedora compiled with SSE4/AVX/AVX2 and not
just guess from Clear Linux results.
I see AVX2 is just too high baseline (although, all my PCs and laptops
support that for at least 2 years), but raising the baseline to something
like AVX or SSE4 might make sense. I don't know why people with *not
ancient* computers should have degraded performance just because we want to
support everything from K8 from 2003. But as I said, it'd be nice to see
some benchmarks to base the decision on and have optimized x86_64 as
secondary arch, if possible.
On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler <kevin.kofler(a)chello.at>
> * the performance increase to be had is marginal, given that we are mostly
> talking about code written in C or C++ without even compiler
> (-ftree-vectorize) turned on,
Are you sure? Fore example (and there are more of them), lots of these do
not seem marginal:
The problem with words like marginal is that what Kevin in his head and
what you have in your head probably mean two different things. Also when I
see such statistics, I usually wonder "Are they repeatable?" Not just in
the case that someone else runs Clear Linux and gets similar timings.. but
if I compile my code with those options do I get those numbers or do I need
to use Clear Linux to do so because there are other changes not taken into
account by just compiling things with an option?
This was something we ran into several times in the past with the race to
keep up with Mandrake or SuSE during the i486/i586/i686 days.. and again
with various super computer rebuilds years later. We can compile the code
with the same options but you may not get the same speeds. There can be
other changes in the structure of the executable chain from kernel down to
file node structure. All of those need to be taken into account to
'duplicate' test results.
Without doing that testing and confirming that we know all the options, we
are no better off than the person who says they compile everything with
Stephen J Smoogen.