[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] This may amuse some people
From: |
Jim Segrave |
Subject: |
[Bug-gnubg] This may amuse some people |
Date: |
Thu, 31 Jul 2003 13:17:50 +0200 |
User-agent: |
Mutt/1.2.5.1i |
Last night I decided to actually use gnubg as opposed to working on
it, I thought I'd play an early evening 7 pointer to see how much I'd
forgotten about backgammon in the last month. I was horrified - it was
unbelievably slow. I ran the calibration test and got 3300 evals/sec,
it used to be 7700 on the same machine.
I immediately fired up a copy I've been using as a reference while
playing with rollouts, built from the June 28 source - that ran
normally - 7500 evals/sec.
I wondered if the python code had affected things - FreeBSD 4.x thread
handling is less than optimal, so I rebuilt the current source without
python. Still slow.
I started doing a binary search in the source, downloading and
building the July 15 version - slow. Tried the July 6 version -
slow. July 1 - slow June 29 - slow.
I began to think I was going crazy, so I downloaded the June 28
version (the exact same CVS timestamps as my reference). It was slow.
I went to bed, totally puzzled.
I was thinking about it and suddenly remembered that just after 28
June, there was a sort of clean-up of compiler warnings. I looked at
the script I use to fetch and build gnubg:
...
export CFLAGS="-g -Wall"
...
./configure --without-python 2>&1 | tee configure.out
gmake 2>&1 | tee make.out
...
The CFLAGS setting was added when I was looking for compiler
warnings. Light dawns, change to:
export CFLAGS="-g -Wall -O2"
and things are back to normal.
Sigh. I never would have expected a factor of 2 degradation if you
turn off optimisation.
-O3 helps a bit, that gives about 7800 evals/sec
--
Jim Segrave address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug-gnubg] This may amuse some people,
Jim Segrave <=