RedQueen 1.1.1 was announced today on the General Topics forum. I built it with
$ g++ -O3 -Wall *.cpp -o redqueen
and the resulting executable plays very weakly, often loses on time and occasionally hangs.
Here's the end of an unexpectedly short match under cutechess-cli with tc=/60+1
...
Finished game 20 (Spandrel vs RedQueen 1.1.1): 1-0 {Black loses on time}
Score of Spandrel vs RedQueen 1.1.1: 17 - 2 - 2 [0.86] 21
Started game 25 of 18000 (Spandrel vs RedQueen 1.1.1)
Finished game 22 (RedQueen 1.1.1 vs Spandrel): 0-1 {Black mates}
Score of Spandrel vs RedQueen 1.1.1: 18 - 2 - 2 [0.86] 22
Started game 26 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 24 (Spandrel vs RedQueen 1.1.1): 1-0 {White mates}
Score of Spandrel vs RedQueen 1.1.1: 19 - 2 - 2 [0.87] 23
Started game 27 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 23 (RedQueen 1.1.1 vs Spandrel): 0-1 {White's connection stalls}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 25 (Spandrel vs RedQueen 1.1.1): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 26 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Unexpected move from "RedQueen 1.1.1"
Unexpected move from "RedQueen 1.1.1"
Finished game 27 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
ELO difference: 338
When I use clang instead of gcc, RedQueen doesn't build.
$ clang++ -O3 -Wall *.cpp -o redqueen
In file included from board.cpp:26:
In file included from ./board.h:37:
./moveiterator.h:108:22: error: array initializer must be an initializer list
Data(Data& data) : list(data.list), size(data.size), idx(data.idx), saveIdx(data.saveIdx), stage(BEGIN_STAGE){};
^
I wonder if these two puzzling observations may be connected in some way. I have OS X 10.7 with clang 3.1.
Robert P.
micron wrote:RedQueen 1.1.1 was announced today on the General Topics forum. I built it with
$ g++ -O3 -Wall *.cpp -o redqueen
and the resulting executable plays very weakly, often loses on time and occasionally hangs.
Here's the end of an unexpectedly short match under cutechess-cli with tc=/60+1
...
Finished game 20 (Spandrel vs RedQueen 1.1.1): 1-0 {Black loses on time}
Score of Spandrel vs RedQueen 1.1.1: 17 - 2 - 2 [0.86] 21
Started game 25 of 18000 (Spandrel vs RedQueen 1.1.1)
Finished game 22 (RedQueen 1.1.1 vs Spandrel): 0-1 {Black mates}
Score of Spandrel vs RedQueen 1.1.1: 18 - 2 - 2 [0.86] 22
Started game 26 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 24 (Spandrel vs RedQueen 1.1.1): 1-0 {White mates}
Score of Spandrel vs RedQueen 1.1.1: 19 - 2 - 2 [0.87] 23
Started game 27 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 23 (RedQueen 1.1.1 vs Spandrel): 0-1 {White's connection stalls}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 25 (Spandrel vs RedQueen 1.1.1): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 26 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Unexpected move from "RedQueen 1.1.1"
Unexpected move from "RedQueen 1.1.1"
Finished game 27 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
ELO difference: 338
When I use clang instead of gcc, RedQueen doesn't build.
$ clang++ -O3 -Wall *.cpp -o redqueen
In file included from board.cpp:26:
In file included from ./board.h:37:
./moveiterator.h:108:22: error: array initializer must be an initializer list
Data(Data& data) : list(data.list), size(data.size), idx(data.idx), saveIdx(data.saveIdx), stage(BEGIN_STAGE){};
^
I wonder if these two puzzling observations may be connected in some way. I have OS X 10.7 with clang 3.1.
Robert P.
Hi Robert,
Thanks for giving it a try on Mac. Something is definitely wrong with either the build or the time management routine. I usually test with fast time controls (40/60, 40/300 and 5 Min whole game) using cutechess-cli. There was very few loses on time.
I have done some changes in time management routines for this version. Maybe I broke the code for this specific time control along the way. I'll see this and let you know if there's something wrong in the code. Anyway this doesn't explain the very weak play. It should be playing above the 2700 Elo mark.
micron wrote:RedQueen 1.1.1 was announced today on the General Topics forum. I built it with
$ g++ -O3 -Wall *.cpp -o redqueen
and the resulting executable plays very weakly, often loses on time and occasionally hangs.
Here's the end of an unexpectedly short match under cutechess-cli with tc=/60+1
...
Finished game 20 (Spandrel vs RedQueen 1.1.1): 1-0 {Black loses on time}
Score of Spandrel vs RedQueen 1.1.1: 17 - 2 - 2 [0.86] 21
Started game 25 of 18000 (Spandrel vs RedQueen 1.1.1)
Finished game 22 (RedQueen 1.1.1 vs Spandrel): 0-1 {Black mates}
Score of Spandrel vs RedQueen 1.1.1: 18 - 2 - 2 [0.86] 22
Started game 26 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 24 (Spandrel vs RedQueen 1.1.1): 1-0 {White mates}
Score of Spandrel vs RedQueen 1.1.1: 19 - 2 - 2 [0.87] 23
Started game 27 of 18000 (RedQueen 1.1.1 vs Spandrel)
Finished game 23 (RedQueen 1.1.1 vs Spandrel): 0-1 {White's connection stalls}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 25 (Spandrel vs RedQueen 1.1.1): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Finished game 26 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
Unexpected move from "RedQueen 1.1.1"
Unexpected move from "RedQueen 1.1.1"
Finished game 27 (RedQueen 1.1.1 vs Spandrel): * {No result}
Score of Spandrel vs RedQueen 1.1.1: 20 - 2 - 2 [0.88] 24
ELO difference: 338
When I use clang instead of gcc, RedQueen doesn't build.
$ clang++ -O3 -Wall *.cpp -o redqueen
In file included from board.cpp:26:
In file included from ./board.h:37:
./moveiterator.h:108:22: error: array initializer must be an initializer list
Data(Data& data) : list(data.list), size(data.size), idx(data.idx), saveIdx(data.saveIdx), stage(BEGIN_STAGE){};
^
I wonder if these two puzzling observations may be connected in some way. I have OS X 10.7 with clang 3.1.
Robert P.
Hi Robert,
Thanks for giving it a try on Mac. Something is definitely wrong with either the build or the time management routine. I usually test with fast time controls (40/60, 40/300 and 5 Min whole game) using cutechess-cli. There was very few loses on time.
I have done some changes in time management routines for this version. Maybe I broke the code for this specific time control along the way. I'll see this and let you know if there's something wrong in the code. Anyway this doesn't explain the very weak play. It should be playing above the 2700 Elo mark.
Regards,
I tested your Linux 64-bit compile and got the same problem. So there must be something wrong in the code, and the problem is not linked to his mac compile. Things to look for:
* is the allocated time always less than the remaining time minus buffer ?
* how frequent is the polling code called ?
lucasart wrote:
I tested your Linux 64-bit compile and got the same problem. So there must be something wrong in the code, and the problem is not linked to his mac compile. Things to look for:
* is the allocated time always less than the remaining time minus buffer ?
* how frequent is the polling code called ?
Commenting out the code (+incTime) above should "fix" the problem. But I am not sure what is the best approach for handling time control with increments...
Commenting out the code (+incTime) above should "fix" the problem. But I am not sure what is the best approach for handling time control with increments...
No that's not a fix. It's replacing a bug for another
where
* remaining_time is whaterever you received from the wtime or btime parameter of the go command
* buffer is some small time buffer, like 25ms for example, which should cover the GUI lag, as well as the lag in your engine for reading and processing the position command.
The choice of buffer depends on the GUI lag. HG Muller has done some testing on that, with xboard and cutechess-cli. IMO 25ms should be sufficient. You can use something larger, especially to accomodate for very slow interfaces like Arena.
Commenting out the code (+incTime) above should "fix" the problem. But I am not sure what is the best approach for handling time control with increments...
No that's not a fix. It's replacing a bug for another
where
* remaining_time is whaterever you received from the wtime or btime parameter of the go command
* buffer is some small time buffer, like 25ms for example, which should cover the GUI lag, as well as the lag in your engine for reading and processing the position command.
The choice of buffer depends on the GUI lag. HG Muller has done some testing on that, with xboard and cutechess-cli. IMO 25ms should be sufficient. You can use something larger, especially to accomodate for very slow interfaces like Arena.
Lucas,
Your "remaining_time" is actually what I have in the "time" variable.
On earlier versions I had a fixed time buffer and got a lot of problems when using Arena (under windows). Although it was working fine under Linux - cutechess-cli/XBoard (NOT with the incremental TC though - I was not testing very often with this TC before)
BTW, I agree about the "horrible hacks"..
As I said you need only cap the time by the remaining time (with lag buffer). What about this ?
You can also make the 25ms an UCI option, rather than hardcode it as I did. It would allow users of Arena (and other slow GUIs) able to change it to suit their need.
You can also make the 25ms an UCI option, rather than hardcode it as I did. It would allow users of Arena (and other slow GUIs) able to change it to suit their need.
I can also try running a very fast hardware benchmark on the initialization of the engine, so that it will automatically set a more adequate time buffer (limited by a hardcoded lower and upper bound).