[Bug stdio/21127] printf functions can take much memory with %g when the format precision is large

[Bug stdio/21127] printf functions can take much memory with %g when the format precision is large

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21127

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-05-06
                 CC|                            |carlos at redhat dot com
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
For modern glibc (last 2 years) the digit printing goes through
__vfprintf_internal, and uses the __printf_buffer code that Florian Weimer
added in 2022.

The __printf_buffer code manages to print the test case without using more than
a ~295MiB of heap at peak usage to compute the internal result.

The test is still quite slow because we need to use multi-precision digits to
compute the result e.g. __printf_fp_buffer_1() -> hack_digit().

As we cross from 10.5 -> 9.5 things change. Internally scalesize drops to zero
and the fracsize goes up to 2, this is the cut-point in the internal
algorithm's optimization.

I can confirm that this is the reason you see the transition in performance,
and I can confirm that it takes a lot of memory to compute a correct answer to
the number of requested digits.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/21127] printf functions can take much memory with %g when the format precision is large

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21127

--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Beyond 16494 digits after the decimal point (FLT128_TRUE_MIN is 2**-16494 and
so can be represented exactly in 16494 digits after the decimal point), all
digits must be zero (and there are at most 4933 digits before the decimal
point), so a smarter implementation would bound the memory needed internally
and not need to store all the extra 0s in order to output them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.