what is the fastest time control that it is possible to test engines?

[Uri Blass]

Is there a rating list for this time control?

The fastest time control that I can see in banksia gui is 1 millisecond per game and I wonder if there are engines that can play in this time control.

In theory you can play at least 500 games per second with this time control so you can test changes very fast but the question is if there are engines that can practically play without losing on time very fast(the best strategy for rating may be to allow the engine to lose on time in case of a long game and never look at the clock because it cost time).

[towforce]

This is guessing rather than informed comment, but I think you're going to need to set a time per move rather than a time for the whole game, otherwise the engines will just keep running out of time.

For short times to produce worthwhile results, you'll probably also need an engine with a very fast HCE, and a very fast tree search to avoid making bad mistakes.

To play better than random, you need some knowledge about the position, and there are two ways to get this knowledge:

1. Build knowledge into the engine

2. Generate the knowledge on the fly by building a game tree

Option (1) is preferable, but is subject to error in positions where this knowledge doesn't apply well.

[Uri Blass]

This is guessing rather than informed comment, but I think you're going to need to set a time per move rather than a time for the whole game, otherwise the engines will just keep running out of time.

For short times to produce worthwhile results, you'll probably also need an engine with a very fast HCE, and a very fast tree search to avoid making bad mistakes.

To play better than random, you need some knowledge about the position, and there are two ways to get this knowledge:

1. Build knowledge into the engine

2. Generate the knowledge on the fly by building a game tree

Option (1) is preferable, but is subject to error in positions where this knowledge doesn't apply well.

To play better than random some piece square table+one ply search should be enough.

If we assume 100 nodes per move then you need 0.1 millisecond per move with 1M nodes per second or 0.01 millisecond per move with 10M nodes per move.

The main question is if the computer is designed to measure accurately these small times.

[towforce]

The main question is if the computer is designed to measure accurately these small times.

Again, a guess - but I'm going to say "no": the main reason is that APIs between programs will usually cause some lag, but also because there will be some overheads in the chess programs themselves - like interpreting the move and preparing to start the analysis of it. At these low times, even a garbage sweep (which I'm guessing will be needed in a chess program building game trees and hash tables (assuming that the memory allocation for these are not fixed)) will have an impact!

[Dann Corbit]

What that rating list would tell you is what chess engines were best at game in one millisecond.
I suspect that some engines can probably play that fast, and some people do like to play chess ultra-fast (I don't).
But at speed like that I think engines will play differently to some degree from even bullet chess.

[Uri Blass]

What that rating list would tell you is what chess engines were best at game in one millisecond.
I suspect that some engines can probably play that fast, and some people do like to play chess ultra-fast (I don't).
But at speed like that I think engines will play differently to some degree from even bullet chess.

I think that playing best at the fastest time control may force engines to take logical decisions at small depths.

For example here modern engines blunder by Nxb5 because they prune Qxb5 that I consider to be stupid pruning and I guess that engines can become better at very fast time control by detecting pins and understanding that you do not need to prune Qxb5 in the search

[d]2r2rk1/pq3ppp/3bpn2/1p6/2PNP1PP/P3BP2/1PQ5/R3K2R w KQ - 0 18

Maybe game in one milloisecond is too fast to avoid Nxb5 but I do not believe that pruning Qxb5 also at depth 2 and 3 and 4 is really the best idea for engines for very fast time control.

My idea for developing new chess engine is first to optimize for the fastest time control that you can use and later use a different strategy for slower time control by different rules of evaluation and search with a bigger iteration(when maybe the different rules may make the engine slightly slower and slightly weaker at very fast time control but it is not going to be totally blind to simple tactics that humans can easily see at very fast time control because the programmer does not care.

[mar]

Maybe game in one milloisecond is too fast to avoid Nxb5 but I do not believe that pruning Qxb5 also at depth 2 and 3 and 4 is really the best idea for engines for very fast time control.

the problem with (sub)millisecond games is that UCI quantizes all time to milliseconds, that's not enough resolution to play 1msec games
also one would have to change (some) engines to support sub-msec timing themselves (for example, my engine only has 1msec internal resolution)

the engines themselves should be able to handle sub-ms tc on modern hw

I think 1 sec games with increment should be doable.

the fastest rating list I'm aware of is Alex Brunetti's e4e6.com here: https://e4e6.com/