[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
From: Stephen John Smoogen <smooge () gmail ! com>
Date: 2019-07-31 14:08:40
Message-ID: CANnLRdgiqY4AWXDHTFCv1F88+oBE7_eZKbCNMS72W=eYs=TpaQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, 31 Jul 2019 at 09:15, Frantisek Zatloukal <fzatlouk@redhat.com>
wrote:
> Personally, I am not at all against raising the bar for baseline x86_64.
> 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@chello.at>
> wrote:
>
>> * the performance increase to be had is marginal, given that we are mostly
>> talking about code written in C or C++ without even compiler
>> vectorization
>> (-ftree-vectorize) turned on,
>>
>
> Are you sure? Fore example (and there are more of them), lots of these do
> not seem marginal:
> https://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-2019-Python-Perf
> ,
> https://www.phoronix.com/scan.php?page=article&item=linux-2016-2018&num=3
>
>
>
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
-funrolloops
--
Stephen J Smoogen.
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, 31 Jul 2019 at 09:15, Frantisek Zatloukal <<a \
href="mailto:fzatlouk@redhat.com">fzatlouk@redhat.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>Personally, I am not at all against raising the bar for baseline \
x86_64. 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.</div><div><br></div><div>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. </div><div dir="ltr"><br></div><div dir="ltr">On Wed, Jul 31, \
2019 at 11:00 AM Kevin Kofler <<a href="mailto:kevin.kofler@chello.at" \
target="_blank">kevin.kofler@chello.at</a>> wrote:</div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* the performance increase to be had is marginal, given that we are mostly<br>
talking about code written in C or C++ without even compiler vectorization<br>
(-ftree-vectorize) turned on,<br></blockquote><div><br></div><div>Are you sure? \
Fore example (and there are more of them), lots of these do not seem marginal: <a \
href="https://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-2019-Python-Perf" \
target="_blank">https://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-2019-Python-Perf</a> \
, <a href="https://www.phoronix.com/scan.php?page=article&item=linux-2016-2018&num=3" \
target="_blank">https://www.phoronix.com/scan.php?page=article&item=linux-2016-201 \
8&num=3</a></div><div><br></div><div><br></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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. \
</div><div><br></div><div>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 -funrolloops </div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic