Games/second Engines

[jhaglund2]

It's been a couple years. I'm looking for any engine that does games per second to choose it's move.

Engines can do over 100 million nodes per second with today's hardware (e.g., AMD 5950X).
How many games per second do you think you can get your engine to do? Average game of chess ~37 moves.

I haven't seen anything talked about. Was wondering if anything has been in the works.
Thanks

[Kotlov]

It's been a couple years. I'm looking for any engine that does games per second to choose it's move.

Stockfish with movetime 1000?

[lithander]

Many engine programmers use ultra fast time controls for testing. With 1 second + 100ms strong engines still play at grandmaster level.
If you want to play dozens of hundreds of games per second I would assume the whole overhead of using a GUI and an engine thread that you talk to with text commands becomes a bottleneck and needs to be removed.

I could write a program in C# in a day that utilizes my chess engine's search routine directly to play hundreds of games per second utilizing all available cores... theses games would be pretty shallow in terms of search depth but otherwise they will just be normal chess games like you'd expect them from an engine with 200 Elo less when given a more normal amount of time. But.. why would I want to do that?

[hgm]

It is not advisable to play sub-second games with conventional engines communicating through a GUI. Communication delays will be too long and too unpredictable.

You can do such a thing for self-play when you write a routine for that inside the engine itself. But even then maniging the time by wall-clock would be a bad idea. There will be unpredictable lapses where the process doesn't get any CPU time or will be partly swapped out of memory because of hidden tasks the OS occasionally performs. So it would be better to play by number of nodes rather than time.

This is what I did in my Janggi engine. I equipped it with some extra commands, so that I can run it from the command line, and play a requested number of games with a given number of nodes per move. Positions are sampled from these games (in particular the positions at the end of the PV, as these are quiet) for collecting a set to tune the eval on.

[jhaglund2]

Many engine programmers use ultra fast time controls for testing. With 1 second + 100ms strong engines still play at grandmaster level.
If you want to play dozens of hundreds of games per second I would assume the whole overhead of using a GUI and an engine thread that you talk to with text commands becomes a bottleneck and needs to be removed.

There's no where I mention you need to do additional talking to a GUI while doing the crunching of games.

Code: Select all

I could write a program in C# in a day that utilizes my chess engine's search routine directly to play hundreds of games per second utilizing all available cores... theses games would be pretty shallow in terms of search depth but otherwise they will just be normal chess games like you'd expect them from an engine with 200 Elo less when given a more normal amount of time. But.. why would I want to do that?

Please do!
Yes, that's the part where tuning, and other methods to get a complete game would come in before you decide to increment to the next move in your PV.

If you can do 100 million nps. I think 5k-20k and upwards of 50k games/sec would be a good goal.

[jhaglund2]

It is not advisable to play sub-second games with conventional engines communicating through a GUI. Communication delays will be too long and too unpredictable.

Correct.

You can do such a thing for self-play when you write a routine for that inside the engine itself. But even then maniging the time by wall-clock would be a bad idea. There will be unpredictable lapses where the process doesn't get any CPU time or will be partly swapped out of memory because of hidden tasks the OS occasionally performs. So it would be better to play by number of nodes rather than time.

Games / Second is just a benchmark how fast the engine completes games. Similar to Nodes per Second. It doesn't imply it's based on a clock.

This is what I did in my Janggi engine. I equipped it with some extra commands, so that I can run it from the command line, and play a requested number of games with a given number of nodes per move. Positions are sampled from these games (in particular the positions at the end of the PV, as these are quiet) for collecting a set to tune the eval on.

Tuning is certainly a part of the process. How you want to complete a game, statistics for the root moves have to be done, etc. Think of it like a chess database being created for each move.

[jhaglund2]

Stockfish with movetime 1000?

I'm not aware Stockfish does games/second for move selection.

[hgm]

Well, if your search can do 1Mnps, and you want to do 10 games per second, you have 100k nodes per game. If a game lasts 100 half-moves you have 1k nodes per move. It should be possible to search some 3 ply + QS with that.

Multi-threaded engines could probably do more nps, but you would spend the CPU time better by playing a number of single-threaded games in parallel.

Of course you can also play games with a 1-ply search + QS. That might take only 100 nodes per move. Quality would suffer, but they would still be games.

[lithander]

You could also make a "game tree" where games with a common ancestry all had the same moves made up to the point where they branch off. Can generate a lot of games that way that start the same but then end differently!

[jhaglund2]

Well, if your search can do 1Mnps, and you want to do 10 games per second, you have 100k nodes per game. If a game lasts 100 half-moves you have 1k nodes per move. It should be possible to search some 3 ply + QS with that.

That is part of the tuning, how to arrive at a concluded game. I'd rather see more data points / games.

Multi-threaded engines could probably do more nps, but you would spend the CPU time better by playing a number of single-threaded games in parallel.

1 thread per root move possible and iterate is what comes to mind.

Of course you can also play games with a 1-ply search + QS. That might take only 100 nodes per move. Quality would suffer, but they would still be games.

Plenty of options here.