[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65ed5ed4-d8e7-fd2e-976-66ee169e973b@dereferenced.org>
Date: Sun, 15 Aug 2021 09:57:51 -0500 (CDT)
From: Ariadne Conill <ariadne@...eferenced.org>
To: Rich Felker <dalias@...c.org>
cc: Ariadne Conill <ariadne@...eferenced.org>, musl@...ts.openwall.com,
Szabolcs Nagy <nsz@...t70.net>
Subject: Re: [PATCH #2] Properly simplified nextafter()
Hi,
On Sun, 15 Aug 2021, Rich Felker wrote:
> On Sun, Aug 15, 2021 at 02:46:58AM -0500, Ariadne Conill wrote:
>> On Sun, 15 Aug 2021, Stefan Kanthak wrote:
>>> [stefan@...e ~]$ gcc --version
>>> gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
>>> Copyright (C) 2018 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> gcc 8 is quite old at this point. gcc 9 and 10 have much better
>> optimizers that are much more capable.
>>
>> Indeed, on my system with GCC 10.3.1, nextafter() is using SSE2
>> instructions on Alpine x86_64, and if I rebuild musl with
>> `-march=znver2` it uses AVX instructions for nextafter(), which
>> seems more than sufficiently optimized to me.
>
> As far as I can tell, the instructions used are not the issue here,
> and there are no specialized instructions that help make it faster. If
> GCC is doing a bad job, it's more a matter of the high level flow,
> choice of how to load constants, how branches are implemented, etc.
Right, I'm just more saying that at least from what I see at glancing at
the disassembly in both cases, the code generated by GCC 10 does not seem
particularly bad.
(And nitpicking in the aggressive way Stefan is doing over 3 nsec per call
in something that really is not generally a fastpath is kind of silly
anyway.)
Ariadne
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
