Re: GCC Optimisation status update

[Dimitrios Apostolou <jimis at gmx dot net>]

Hi Jakub,

On Tue, 14 Jun 2011, Jakub Jelinek wrote:
> On Tue, Jun 14, 2011 at 03:13:00PM +0300, Dimitrios Apostolou wrote:
> > parsing overhead and the hex conversion (implemented suboptimally in
>
> Can you back that up?  glibc conversion to hex representation is fairly
> heavily optimized, see _itoa_word in stdio-common/_itoa.h.  In fact, I'd
> say it is much better than your implementation.  The overhead
> you may see almost certainly comes from the fact that printf family
> have to handle lots of different stuff, including narrow/wide output,
> optional groupping, localized digits and all kinds of other things.

It's true that I saw but didn't really understand glibc's _itoa(), and 
just assumed it was slower since it works for all base, not only base 
16 which is special. Nevertheless my measurements showed puthexl()
faster, and the genericity of the function is certainly an important 
factor.

If _itoa() indeed has a better algorithm I could use it.

> > glibc) I changed the hottest callers with fwrite()/fputs() and
> > implemented a puthexl() function for hex conversion:
> >
> > static void puthexl (unsigned long value, FILE *f)
> > {
> >   static char hex_repr[16]= {'0', '1', '2', '3', '4', '5', '6', '7',
> > 			     '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
> >   static char buf[2 + 2*sizeof(value)]= "0x";
> >   int i;
> >   int j= 2;
> >
> >   for (i = 8*sizeof(value)-4; i>=0; i-= 4)
> >     {
> >       char c= (value >> i) & 0xf;
> >       if (c!=0 || j>2)
> > 	{
> > 	  buf[j]= hex_repr[(int)c];
>
> Why not just "0123456789abcdef"[c] instead

Code just looked more beautiful, that's all. :-)

> (and make c an int, instead of char).

done

> Furthermore, consider instead of filling from the beginning filling from the end.

My first version (out of 5 others) was doing that. I think there was no 
actual performance difference, and filling from start helped skipping 
leading zeroes and appending right after "0x".

> buf shouldn't be static.

buf initialisation time I avoid that way is almost negligible, so I could 
change it if necessary. But what is the problem with it being static?

> Hardcoding CHAR_BIT to 8 is not portable.

Changed, didn't have a clue about that issue! I'll be delighted to learn 
which platform has CHAR_BIT != 8 :-)

Thanks for your comments,
Dimitris