Re: memchr2 speed, gcc

[Bruno Haible]

Eric Blake wrote:
> it would be interesting to see your 
> timings by swapping the typedef to try 64-bit math with newer gcc again.  For 
> that matter, is it worth putting a preprocessor conditional to change the 
> typedef according to whether the compiler appears to be a new enough version 
> of 
> gcc to intelligently optimize the 64-bit math?

Here are the test results. Same test program and machine as in
  http://lists.gnu.org/archive/html/bug-gnulib/2008-03/msg00045.html
Timings are in seconds, for 100000 runs.

Variant M is the one with uintmax_t, variant L the one with 'unsigned long'
(i.e. what is now committed).

                           M      L

gcc-3.2.2                 6.38   4.68
gcc-3.2.2 -mcpu=athlon    6.10   4.64
gcc-4.2.2                 6.55   5.29
gcc-4.2.2 -mtune=athlon   6.10   4.94
gcc-4.3-ss                6.10   5.84
gcc-4.3-ss -mtune=athlon  5.81   5.30
gcc-4.3.0                 6.10   5.84
gcc-4.3.0 -mtune=athlon   5.81   5.30

Summary of results:
  - Variant L is always optimized better than variant M.
  - While for variant M newer gccs give better code than older gccs,
    for variant L it is the opposite: Here older gccs are better.
  - Variant L is better than LO/LS from last time for gcc-3.2.2 and gcc-4.2.2,
    but for gcc-4.3 it's the opposite.

Note also that -fomit-frame-pointer should be avoided with gcc-4.x. Here are
the comparative results for L:

                           L    L + -fomit-frame-pointer

gcc-3.2.2 -mcpu=athlon    4.64   4.64
gcc-4.2.2 -mtune=athlon   4.94   5.07
gcc-4.3-ss -mtune=athlon  5.30   5.87
gcc-4.3.0 -mtune=athlon   5.30   5.87

Bruno