Re: GCC Optimisation status update

2011-06-14 Thread H.J. Lu
On Tue, Jun 14, 2011 at 2:51 PM, wrote: > >> We are working on a patch which will improve decimal >> itoa by up to 10X.  It will take a while to finish it. > > What's the method? > We use SSSE3 and SSE4 instructions for shift and multiply. -- H.J.

Re: GCC Optimisation status update

2011-06-14 Thread zoltan
> We are working on a patch which will improve decimal > itoa by up to 10X. It will take a while to finish it. What's the method? I have a function converting 32 bit unsigneds to decimal which costs one 32x32->64 multiply with a constant (a single constant, not a look-up table) plus a max. 8-ti

Re: GCC Optimisation status update

2011-06-14 Thread Dimitrios Apostolou
Hi Jakub, On Tue, 14 Jun 2011, Jakub Jelinek wrote: You'd use it as: void puthexl (unsigned long value, FILE *f) { char buf[2 + CHAR_BIT * sizeof (value) / 4]; if (value == 0) putc ('0', f); else { char *p = buf + sizeof (buf); do *--p = "0123456789abcdef"[value % 16];

Re: GCC Optimisation status update

2011-06-14 Thread H.J. Lu
On Tue, Jun 14, 2011 at 8:21 AM, Jakub Jelinek wrote: > On Tue, Jun 14, 2011 at 05:59:47PM +0300, Dimitrios Apostolou wrote: >> >>static void puthexl (unsigned long value, FILE *f) >> >>{ >> >>  static char hex_repr[16]= {'0', '1', '2', '3', '4', '5', '6', '7', >> >>                         '8', '

Re: GCC Optimisation status update

2011-06-14 Thread Jakub Jelinek
On Tue, Jun 14, 2011 at 05:59:47PM +0300, Dimitrios Apostolou wrote: > >>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 +

Re: GCC Optimisation status update

2011-06-14 Thread Dimitrios Apostolou
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_wo

Re: GCC Optimisation status update

2011-06-14 Thread Jakub Jelinek
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 muc

GCC Optimisation status update

2011-06-14 Thread Dimitrios Apostolou
Hello list, I've been working on my project full time since last week, and on a part-time basis before then. Hopefully I'll be posting updates/patches more often now that my exams are over. For anyone that wants to talk to me, I'm jimis on the IRC. I've looked a little into hash tables, symt