RFC: fp printing speedup patch

[Paolo Carlini]

Jerry Quinn wrote:

>Hi, folks.  After way too long, I've finally gotten working a patch to integrate
>the libio fp printing code into the library.  For the example in the
>performance testsuite, this is worth a 3.5x speedup, since the routines use
>doubles in place of big int computations.
>
>The catch (of course there's a catch) is that printing numbers not handled by
>the fp optimizations are something like 2x slower than sprintf.  This happens
>when printing with more than about 15 digits of precision for double.  For
>general printing, this patch is MUCH faster.
>
Another couple of comments wrt performance:

    1- If I understand well, besides the very good thing of removing 
printf and
       the ugly complexity of __convert_from_v, it's a matter of 
trade-offs: the
       dtoa code used in v2, which you have adapted now, favor low 
precision,
       whereas (glibc) printf favors high precision. I don't have a very 
clear
       position right now: how "big" is a ""typical"" floating point number?

    2- About your numbers something puzzles me. I did a tiny-tiny 
experiment for
       this code adapted from libstdc++/7076 (P4-2400, -O2, > /dev/null):

            for (float i = 0; i < 3000000; i++)
              std::cout << i << '\n';
      
       3.3.2 --- 15.880u 0.010s 0:16.52 96.1%    0+0k 0+0io 221pf+0w
       3.4 ----- 6.520u 0.000s 0:06.57 99.2%     0+0k 0+0io 211pf+0w
       2.96-99 - 4.120u 0.010s 0:04.24 97.4%     0+0k 0+0io 143pf+0w
    
       So, if the dtoa code that you have moved is by and large 
equivalent to that
       present in v2 (it is, right?), the performance improvement you 
have abtained
       for "small" numbers (~3.5x) seems *way* too good, since we would 
*largely*
       outperform v2 as shipped with 2.96-99!

       Also, it looks like, for a small number of digits in mainline we 
are not
       doing that bad... and for a big number of digits performance-wise 
printf
       wins... hummm

Ideas?

Paolo.