JuLieN wrote:Well, sorry guys, but I can't get a single Double Check compile to work under OSX Lion I tried lots of various gcc versions, even the latest gcc 4.7 beta, and all of them end-up the same way :
DoubleCheck 2.5 JA by Lucas Braesch
Copyright (C) 2011 Lucas Braesch
uci
id name DoubleCheck 2.5
id author Lucas Braesch
option name Hash type spin default 32 min 1 max 8192
option name Verbose type check default true
uciok
ucinewgame
go movetime 10000
info depth 1
Assertion failed: (B->initialized), function board_is_check, file board.h, line 105.
Abort trap: 6
Of course B->initialized is false, because you didn't specify a position command. Try this
uci
ucinewgame
position startpos
go movetime 100
quit
Note that the UCI protocol never assumes that the absence of a positio command should mean the engine sets it to the startpos (although I'm sure many engines do, just in case, but DC doesn't)
JuLieN wrote:Well, sorry guys, but I can't get a single Double Check compile to work under OSX Lion I tried lots of various gcc versions, even the latest gcc 4.7 beta, and all of them end-up the same way :
DoubleCheck 2.5 JA by Lucas Braesch
Copyright (C) 2011 Lucas Braesch
uci
id name DoubleCheck 2.5
id author Lucas Braesch
option name Hash type spin default 32 min 1 max 8192
option name Verbose type check default true
uciok
ucinewgame
go movetime 10000
info depth 1
Assertion failed: (B->initialized), function board_is_check, file board.h, line 105.
Abort trap: 6
Of course B->initialized is false, because you didn't specify a position command. Try this
uci
ucinewgame
position startpos
go movetime 100
quit
Note that the UCI protocol never assumes that the absence of a positio command should mean the engine sets it to the startpos (although I'm sure many engines do, just in case, but DC doesn't)
So all has been well right from the start, though Julien mistakenly believed otherwise, and also convinced me there was a problem. Perhaps it would make sense to initialize the board to startpos in response to ucinewgame, even though the uci standard doesn't require this. This might help out some GUIs and some buggy human users.
JuLieN wrote:Well, sorry guys, but I can't get a single Double Check compile to work under OSX Lion I tried lots of various gcc versions, even the latest gcc 4.7 beta, and all of them end-up the same way :
DoubleCheck 2.5 JA by Lucas Braesch
Copyright (C) 2011 Lucas Braesch
uci
id name DoubleCheck 2.5
id author Lucas Braesch
option name Hash type spin default 32 min 1 max 8192
option name Verbose type check default true
uciok
ucinewgame
go movetime 10000
info depth 1
Assertion failed: (B->initialized), function board_is_check, file board.h, line 105.
Abort trap: 6
Of course B->initialized is false, because you didn't specify a position command. Try this
uci
ucinewgame
position startpos
go movetime 100
quit
Note that the UCI protocol never assumes that the absence of a positio command should mean the engine sets it to the startpos (although I'm sure many engines do, just in case, but DC doesn't)
So all has been well right from the start, though Julien mistakenly believed otherwise, and also convinced me there was a problem. Perhaps it would make sense to initialize the board to startpos in response to ucinewgame, even though the uci standard doesn't require this. This might help out some GUIs and some buggy human users.
Yeah, I'll probably do that, it doesn't cost much (one line of code).
* ucinewgame
this is sent to the engine when the next search (started with "position" and "go") will be from
a different game. This can be a new game the engine should play or a new game it should analyse but
also the next position from a testsuite with positions only.
If the GUI hasn't sent a "ucinewgame" before the first "position" command, the engine shouldn't
expect any further ucinewgame commands as the GUI is probably not supporting the ucinewgame command.
So the engine should not rely on this command even though all new GUIs should support it.
As the engine's reaction to "ucinewgame" can take some time the GUI should always send "isready"
after "ucinewgame" to wait for the engine to finish its operation.
But Double Check is the first engine I see not to set the board to startup position after a "ucinewgame" command. (And I compiled a lots of them...)
I'd be curious to know the speed difference (on a ./DC bench) between the real gcc and the llvm gcc. According to wikipedia, llvm executables should typically be 10% slower than gcc ones.
lucasart wrote:I'd be curious to know the speed difference (on a ./DC bench) between the real gcc and the llvm gcc. According to wikipedia, llvm executables should typically be 10% slower than gcc ones.
Some results on my Core i5 iMac:
gcc4-7: nodes = 11264189 time = 11.731965
llvm : nodes = 11264189 time = 11.715361
So nearly no difference. But actually the llvm builds tend to be faster than the gcc ones, because of the run-time optimizations (this is the whole idea behind llvm).
lucasart wrote:I'd be curious to know the speed difference (on a ./DC bench) between the real gcc and the llvm gcc. According to wikipedia, llvm executables should typically be 10% slower than gcc ones.
Some results on my Core i5 iMac:
gcc4-7: nodes = 11264189 time = 11.731965
llvm : nodes = 11264189 time = 11.715361
So nearly no difference. But actually the llvm builds tend to be faster than the gcc ones, because of the run-time optimizations (this is the whole idea behind llvm).
I almost hate to bring this up, but why is your benchmark node count not 4889484? Did you modify the search depths for the benchmark positions?
Speaking of speeds, it seems to me that -flto has essentially no effect on the speed of the binary, at least when compiled with gcc-4.6.
I tried lots of various gcc versions, even the latest gcc 4.7 beta, and all of them end-up the same way :
(And I compiled a lots of them...)