libquadmath, glibc, and the Q format flag

libquadmath, glibc, and the Q format flag

[Florian Weimer]

I recently discovered that libquadmath registers custom printf callbacks
on load.  As far as I can tell, this is done so that the Q format flag
can be used to print floating point numbers, using format strings such
as "%Qf".  To enable Q flag processing, libquadmath has to register
replacements for all floating point format specifiers (aAeEfFgG).

Unfortunately, this has the side effect that even with out the Q flag,
printing any floating point number enters a generic, slow path in glibc,
prior to the number formatting itself.  The effect is quite pronounced.
For example this admittedly silly benchmarking script

    for i=1,5000000 do
        print(i, i * math.pi)
    end

runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
seconds.

This impacts most (all?) Fortran code on GNU/Linux because libgfortran
depends on libquadmath.

Would it make sense to transplant the implementation of the Q specifier
from libquadmath to glibc, and disable the registration code in
libquadmath if glibc is recent enough?  At least for the targets that
today have float128 support in glibc?

Thanks,
Florian

Re: libquadmath, glibc, and the Q format flag

[Jakub Jelinek]

On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
> I recently discovered that libquadmath registers custom printf callbacks
> on load.  As far as I can tell, this is done so that the Q format flag
> can be used to print floating point numbers, using format strings such
> as "%Qf".  To enable Q flag processing, libquadmath has to register
> replacements for all floating point format specifiers (aAeEfFgG).
> 
> Unfortunately, this has the side effect that even with out the Q flag,
> printing any floating point number enters a generic, slow path in glibc,
> prior to the number formatting itself.  The effect is quite pronounced.
> For example this admittedly silly benchmarking script
> 
>     for i=1,5000000 do
>         print(i, i * math.pi)
>     end
> 
> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
> seconds.
> 
> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> depends on libquadmath.

Not anymore.
If GCC is configured against new enough glibc (with _Float128 support)
libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
is added only --as-needed to ld command line, so if all the Fortran object
files that need real(kind=16) (or quad complex) are built by such configured
GCC, -lquadmath is not linked in (just needs to be present).
And, even for C, users can just use the standard glibc _Float128 support
(if they don't mind strfromf128) if they target new enough glibc.
So, libquadmath should be left over for non-glibc uses or uses with old
glibc.

> Would it make sense to transplant the implementation of the Q specifier
> from libquadmath to glibc, and disable the registration code in
> libquadmath if glibc is recent enough?  At least for the targets that
> today have float128 support in glibc?

Thus I'm not sure it is worth it.

	Jakub

Re: libquadmath, glibc, and the Q format flag

[Florian Weimer]

* Jakub Jelinek:

> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load.  As far as I can tell, this is done so that the Q format flag
>> can be used to print floating point numbers, using format strings such
>> as "%Qf".  To enable Q flag processing, libquadmath has to register
>> replacements for all floating point format specifiers (aAeEfFgG).
>> 
>> Unfortunately, this has the side effect that even with out the Q flag,
>> printing any floating point number enters a generic, slow path in glibc,
>> prior to the number formatting itself.  The effect is quite pronounced.
>> For example this admittedly silly benchmarking script
>> 
>>     for i=1,5000000 do
>>         print(i, i * math.pi)
>>     end
>> 
>> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
>> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
>> seconds.
>> 
>> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
>> depends on libquadmath.
>
> Not anymore.
> If GCC is configured against new enough glibc (with _Float128 support)
> libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> is added only --as-needed to ld command line, so if all the Fortran object
> files that need real(kind=16) (or quad complex) are built by such configured
> GCC, -lquadmath is not linked in (just needs to be present).

Hmm, I missed that recent change.

Would it make sense to drop the libgfortran RPM dependency on
libquadmath in Fedora rawhide?

> And, even for C, users can just use the standard glibc _Float128 support
> (if they don't mind strfromf128) if they target new enough glibc.
> So, libquadmath should be left over for non-glibc uses or uses with old
> glibc.
>
>> Would it make sense to transplant the implementation of the Q specifier
>> from libquadmath to glibc, and disable the registration code in
>> libquadmath if glibc is recent enough?  At least for the targets that
>> today have float128 support in glibc?
>
> Thus I'm not sure it is worth it.

Yeah, if most implicit libquadmath uses are history, then it's probably
not going to be needed (unless some standard suggests to use the Q
flag).

Thanks,
Florian

Re: libquadmath, glibc, and the Q format flag

[Jakub Jelinek]

On Wed, Feb 01, 2023 at 12:29:02PM +0100, Florian Weimer via Gcc wrote:
> >> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> >> depends on libquadmath.
> >
> > Not anymore.
> > If GCC is configured against new enough glibc (with _Float128 support)
> > libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> > is added only --as-needed to ld command line, so if all the Fortran object
> > files that need real(kind=16) (or quad complex) are built by such configured
> > GCC, -lquadmath is not linked in (just needs to be present).
> 
> Hmm, I missed that recent change.
> 
> Would it make sense to drop the libgfortran RPM dependency on
> libquadmath in Fedora rawhide?

This is a downstream question.
We could drop it from libgfortran (package that contains just the shared
library), but we still need it on gcc-gfortran (as the library is used
during linking for backwards compatibility reasons).

	Jakub