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
