This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] Return of the son of fp printing.


Phil Edwards writes:
 > On Sun, Aug 29, 2004 at 07:11:41PM -0400, Jerry Quinn wrote:
 > > Glibc uses a version of GMP under the
 > > covers for its printing and it seemed like too much work and licensing hassle
 > > to bring it over.
 > 
 > It's already required to build F95, and there's increased pressure to
 > import it into the GCC tree.  So this may not be so far away as you think.

This would be excellent for allowing a local implementation without falling
back to printf.

 > > It seems to have been successful.  The fp printing performance test shows:
 > > 
 > > before:
 > > ofstream_insert_float.cc 	precision 6              	6964r 6534u   79s        0mem    0pf 
 > > ofstream_insert_float.cc 	precision 12             	6836r 6470u   68s        0mem    0pf 
 > > 
 > > after:
 > > ofstream_insert_float.cc 	precision 6              	2914r 2703u   80s        0mem    0pf 
 > > ofstream_insert_float.cc 	precision 12             	3710r 3281u   58s        0mem    0pf 
 > 
 > Wow.

Yeah.  There's some overhead somewhere, because I see about 3x when comparing
lower level code to printf.  Neither of these precision tests pushes the code
into printf, but I expect to see the speed degrade to about equal.  Perhaps
less since we don't have to do an explicit change to global locale and back.

 > > The biggest issue with this patch is that I don't know if adding the exported
 > > symbols to 3.4.2 is the right thing to do.  Wiser heads, let me know.
 > 
 > Mark froze the branch a couple hours ago, so we'll pretend you wrote 3.4.x
 > instead.  :-)

Yeah, I just saw after posting.  Phooey.  What should the linker-map change
look like now?


 > There are formatting and naming issues with the patch (stuff goes past 80
 > characters in several places, there look to be a couple of tabs embedded in
 > a few lines, and stuff in floatconv.cc is going to have to be uglified), but
 > those can be dealt with before checkin.

I'll go back and clean up the 80 char stuff.  Tabs are automatically inserted
by emacs.  I don't remember seeing issues about this before, but I can replace
those as well.

Do we really have to uglify all the static and local stuff in a cc file?  No
symbols there are going to be visible to the outside world.  And uglifying
makes the code so much harder to read :-)

 > > +++ include/bits/locale_facets.tcc	29 Aug 2004 22:22:27 -0000
 > > @@ -36,6 +36,7 @@
 > >  #pragma GCC system_header
 > >  
 > >  #include <limits>		// For numeric_limits
 > > +#include <cmath>		// For log10
 > 
 > Is there no easier (yet safe) way to get log10 than by pulling in the entire
 > math header?  (I don't know, it's an honest question.)

How about __builtin_log10?  More generally, are all these builtins safe on the
3.4 branch?

Jerry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]