[CLN-list] Overriding read_number_bad_syntax on OS X

[Richard B. Kreckel]

Hi!

I did an experiment with CLN 1.1.13. I configured it without GMP and set
CXXFLAGS to -O2 at one time and to "-O2 -fno-exceptions" another time.
The library was built on two diffent hosts, one 32 bit and one 64 bit.
Both shared and static libraries were built.

I then ran the three benchmarks on each of the libraries:
100*exam:  time for i in $(seq 0 100); do ./tests/exam >/dev/null; done
100k*tb2b: time ./benchmarks/timebench2b -r 100000 &>/dev/null
pi 1M:     time ./examples/pi 1000000 >/dev/null

I've disabled cron and did not touch anything while the benchmarks were
running. The results are listed below. An asterisk indicates that the
library was built with -fno-exceptions added to CXXFLAGS.

AMD Opteron 870 2GHz, x86_64 Linux, GCC 4.1 (intDsize=64):
             size  100*exam  100k*tb2b  pi 1M
static,     4.1M    21.81s     47.52s  9.68s
static, *)  3.6M    19.87s     46.84s  9.68s
shared,     1.7M    21.86s     47.76s  9.68s
shared, *)  1.5M    21.91s     47.66s  9.69s

AMD Athon 64, 1.8GHz, i386 Linux, GCC 4.1 (intDsize=32):
             size  100*exam  100k*tb2b  pi 1M
static,     3.1M    31.24s     81.15s  9.25s
static, *)  2.6M    31.01s     81.21s  9.18s
shared,     1.6M    39.79s     91.44s  9.29s
shared, *)  1.3M    37.64s     87.79s  9.28s

It appears that it depends on the architecture whether a shared or a
static library takes a small performance plunge when exceptions are
turned on. The highest performance hit is 9% for the exam test on x86_64
with the static library. That benchmark is the most sensitive one
because, as Bruno has already noticed, it constructs and destructs many
not-so-big numbers. The fact that pi appears slow on x86_64 is due to
missing assembler. This changes dramatically when CLN is configured with
GMP.

Bruno Haible wrote:
 > Is a slowdown of 9% significant?

Well, it depends on whom we ask and when. As you know, the GCC folks are
willing to risk security holes for 9% performance gain on some
benchmarks but then have no qualms releasing a compiler which is 40%
slower on other benchmarks solely because some patches did not make it
for the release. Strange world.

Ron Garret wrote:
> It appears to me that with gcc4, -fno-exceptions has reached the point
 > of diminishing returns.

I am inclined to agree.

   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>