libquadmath, glibc, and the Q format flag
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,500 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
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,500 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
* 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,500 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
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
