RedQueen 1.1.1 on Mac OS X

[micron]

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

Code: Select all

...
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.

Code: Select all

$ 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.

[bhlangonijr]

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

Code: Select all

...
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.

Code: Select all

$ 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,

[lucasart]

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

Code: Select all

...
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.

Code: Select all

$ 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 ?

[bhlangonijr]

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 ?

Hi Lucas,

This is the polling code:

Code: Select all

const bool SimplePVSearch::stop(SearchInfo& info) {
	if ((agent->getSearchNodes()>0 &&
			agent->getSearcher(MAIN_THREAD)->getSearchedNodes() >= agent->getSearchNodes())) {
		return true;
	}
	if (timeIsUp() || agent->shouldStop()) {
		return true;
	}
	return info.splitPoint!=NULL && info.splitPoint->shouldStop;
}

... 

// time is up?
inline const bool SimplePVSearch::timeIsUp() {
	if (searchFixedDepth ||
			infinite || (nodes & nodesToGo)) {
		return false;
	}
	return getTickCount()>=timeToStop;
}

...

The search initialization code:

Code: Select all

// root search
void SimplePVSearch::search(Board board) {
	prepareToSearch();
	setStartTime(getTickCount());
	setTimeToStop();
	searchScore = idSearch(board);
	time = getTickCount()-getStartTime();
}

The frequency of the polling (based on the number of nodes processed):

Code: Select all

nodesToGo = getTimeToSearch&#40;)<=1000?fastNodesToGo&#58;defaultNodesToGo;

....
// constants
const int64_t defaultNodesToGo=0xFFF;
const int64_t fastNodesToGo=0xFF;
....

The problem is in the function that calculates the time to be used by search:

Code: Select all

const int64_t SearchAgent::getTimeToSearch(const int64_t usedTime) {
	if (getSearchMode()==SearchAgent::SEARCH_MOVETIME) {
		return getMoveTime();
	}
	int64_t time=board.getSideToMove()==WHITE? getWhiteTime():getBlackTime();
	//int64_t incTime=board.getSideToMove()==WHITE?getWhiteIncrement():getBlackIncrement();
	int64_t movesLeft = defaultGameSize;
	time-=usedTime;
	if (movesToGo>0) {
		movesLeft = std::min(movesToGo,15);
		if &#40;movesToGo<=2&#41; &#123;
			time=time*70/100;
		&#125; else &#123;
			time=time*99/100;
		&#125;
	&#125; else &#123;
		for &#40;int x=0;x<timeTableSize;x++) &#123;
			if &#40;time<timeTable&#91;x&#93;&#91;1&#93; && time >= timeTable&#91;x&#93;&#91;2&#93;) &#123;
				movesLeft=timeTable&#91;x&#93;&#91;0&#93;+
						&#40;maxGamePhase-board.getGamePhase&#40;))/2;
				break;
			&#125;
		&#125;
		time=time*97/100;
	&#125;
	return time/movesLeft/*+incTime*/;
&#125;

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...

Regards,

[lucasart]

Code: Select all

	return time/movesLeft/*+incTime*/;

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

I suggest a simple

Code: Select all

	return std::min(time / movesLeft + incTime, remaining_time - buffer);

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.

[bhlangonijr]

Code: Select all

	return time/movesLeft/*+incTime*/;

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

I suggest a simple

Code: Select all

	return std::min(time / movesLeft + incTime, remaining_time - buffer);

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.

Code: Select all

int64_t time=board.getSideToMove()==WHITE? getWhiteTime():getBlackTime(); 
// getWhiteTime is the value returned by wtime ...

Then I divide this value by movesToGo... The buffer is applied when initializing the search.

So I guess this part is just fine. I only have to figure out how to handle correctly the increment...

[lucasart]

Your "remaining_time" is actually what I have in the "time" variable.

Not exactly, because of all these horrible hacks:

Code: Select all

		if &#40;movesToGo<=2&#41; &#123;
			time=time*70/100;
		&#125; else &#123;
			time=time*99/100;
		&#125;
...
		time=time*97/100;

As I said you need only cap the time by the remaining time (with lag buffer). What about this ?

Code: Select all

const int64_t SearchAgent::getTimeToSearch(const int64_t usedTime) {
	if (getSearchMode()==SearchAgent::SEARCH_MOVETIME) {
		return getMoveTime();
	}
	int64_t time=board.getSideToMove()==WHITE? getWhiteTime():getBlackTime();
	int64_t incTime=board.getSideToMove()==WHITE?getWhiteIncrement():getBlackIncrement();
	int64_t movesLeft = defaultGameSize;
	time-=usedTime;
	if (movesToGo>0) {
		movesLeft = std::min(movesToGo,15);
	} else {
		for &#40;int x=0;x<timeTableSize;x++) &#123;
			if &#40;time<timeTable&#91;x&#93;&#91;1&#93; && time >= timeTable&#91;x&#93;&#91;2&#93;) &#123;
				movesLeft=timeTable&#91;x&#93;&#91;0&#93;+
						&#40;maxGamePhase-board.getGamePhase&#40;))/2;
				break;
			&#125;
		&#125;
	&#125;
	return std&#58;&#58;min&#40;time-25, time/movesLeft+incTime&#41;;
&#125;

[bhlangonijr]

Your "remaining_time" is actually what I have in the "time" variable.

Not exactly, because of all these horrible hacks:

Code: Select all

		if &#40;movesToGo<=2&#41; &#123;
			time=time*70/100;
		&#125; else &#123;
			time=time*99/100;
		&#125;
...
		time=time*97/100;

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 ?

Code: Select all

        ...
	return std::min(time-25, time/movesLeft+incTime);
}

Yes. It's simple and should fix the bug.

[lucasart]

As I said you need only cap the time by the remaining time (with lag buffer). What about this ?

Code: Select all

        ...
	return std::min(time-25, time/movesLeft+incTime);
}

Yes. It's simple and should fix the bug.

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.

[bhlangonijr]

As I said you need only cap the time by the remaining time (with lag buffer). What about this ?

Code: Select all

        ...
	return std::min(time-25, time/movesLeft+incTime);
}

Yes. It's simple and should fix the bug.

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).