[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memchr2 speed, gcc
From: |
Bruno Haible |
Subject: |
Re: memchr2 speed, gcc |
Date: |
Sat, 26 Apr 2008 13:28:17 +0200 |
User-agent: |
KMail/1.5.4 |
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
- Re: memchr speed, (continued)
Re: memchr2 speed, gcc,
Bruno Haible <=
Re: strchrnul speed, Eric Blake, 2008/04/28
Re: strchrnul speed, Eric Blake, 2008/04/28