This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Optimisation status update
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dimitrios Apostolou <jimis at gmx dot net>
- Cc: gcc at gcc dot gnu dot org, Steven Bosscher <stevenb dot gcc at gmail dot com>, Nicola Pero <nicola dot pero at meta-innovation dot com>
- Date: Tue, 14 Jun 2011 16:09:46 +0200
- Subject: Re: GCC Optimisation status update
- References: <alpine.LNX.2.02.1106141503530.1102@localhost.localdomain>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
> 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 (and make c an int,
instead of char). Furthermore, consider instead of filling from the beginning
filling from the end. buf shouldn't be static.
Hardcoding CHAR_BIT to 8 is not portable.
Jakub