CCRL Blitz, free single-CPU engines

[Kirill Kryukov]

Time control: Equivalent to 40 moves in 4 minutes on Athlon 64 X2 4600+ (2.4 GHz)

In my experience, a number of engines begin to have time management problems when the time control gets much below three minutes. Do you think this will cause problems for the blitz ratings list in the near future?

I did not have any problems so far. I heard that some interfaces (Arena) have problems with short time control, but I don't use it for blitz.

Of course we still have time losses time to time, which we don't use for our rating list. But time losses happen with longer time control too. If time losses happen more often in blitz, it is because 10 blitz games finish in the same time like one long game.

EDIT: In future, when machines are fast enough to run 40/2 or 40/1 (equivalent to current 40/4), it may cause some problems theoretically. May be we'll have to start rounding up when it gets below 3 minutes (instead of rounding to nearest integer minute like now). In more distant future I think we will simply switch to 40/40 (which will become effective 40/10 or less by then).

[Dirt]

Time control: Equivalent to 40 moves in 4 minutes on Athlon 64 X2 4600+ (2.4 GHz)

In my experience, a number of engines begin to have time management problems when the time control gets much below three minutes. Do you think this will cause problems for the blitz ratings list in the near future?

I did not have any problems so far. I heard that some interfaces (Arena) have problems with short time control, but I don't use it for blitz.

Of course we still have time losses time to time, which we don't use for our rating list. But time losses happen with longer time control too. If time losses happen more often in blitz, it is because 10 blitz games finish in the same time like one long game. :-)

EDIT: In future, when machines are fast enough to run 40/2 or 40/1 (equivalent to current 40/4), it may cause some problems theoretically. May be we'll have to start rounding up when it gets below 3 minutes (instead of rounding to nearest integer minute like now). In more distant future I think we will simply switch to 40/40 (which will become effective 40/10 or less by then). :-)

It isn't always about time losses (or crashes - perhaps it was an interface issue after all, but I found the Rybka beta almost always crashed in games of forty moves in ten seconds, repeating), but I recall reports of at least one version of one engine going into hurry up mode for one minute games. That is, it would still have fifty-nine of the sixty seconds left at the time control.

I guess you just need to keep an eye out for any programs that have anomalously poor results on fast computers.

[Kirill Kryukov]

It isn't always about time losses (or crashes - perhaps it was an interface issue after all, but I found the Rybka beta almost always crashed in games of forty moves in ten seconds, repeating), but I recall reports of at least one version of one engine going into hurry up mode for one minute games. That is, it would still have fifty-nine of the sixty seconds left at the time control.

I guess you just need to keep an eye out for any programs that have anomalously poor results on fast computers.

If some program has poor results in fast time control - then this is just how it is. This is the purpose of our testing after all, to measure the performance of different programs in particular time control. If a program does not manage the time well, or does not play well in blitz - we can't do much about it. We can just provide this information and hope that the author takes care of it in the next version.

Also, we (and others) are doing long time control testing as well, so for complete picture information from different sources should be used.

Right now I don't know any program which plays particularly bad in our blitz. In my observation the performance in blitz and in long TC correlate very well for most engines.

BTW, 40 minutes in 10 seconds that you mention is really too fast. Apart from issues some engines may have in such time control, I don't think the results in that time control are very useful or interesting in any case. At least on current day hardware. IMHO.



Best,
Kirill

[Dirt]

If some program has poor results in fast time control - then this is just how it is. This is the purpose of our testing after all, to measure the performance of different programs in particular time control. If a program does not manage the time well, or does not play well in blitz - we can't do much about it. We can just provide this information and hope that the author takes care of it in the next version.

Also, we (and others) are doing long time control testing as well, so for complete picture information from different sources should be used.

Right now I don't know any program which plays particularly bad in our blitz. In my observation the performance in blitz and in long TC correlate very well for most engines.

BTW, 40 minutes in 10 seconds that you mention is really too fast. Apart from issues some engines may have in such time control, I don't think the results in that time control are very useful or interesting in any case. At least on current day hardware. IMHO.

:)

Best,
Kirill

Is it really a useful result if an engine gets rating of 2000 on an Athlon 1200 and, say, 700 on a hot new processor? The final result would say almost nothing about the engine, but only the computers you've chosen to use.

I never considered the ten second games useful. I was seeing occasional crashes at three minutes, but I was unsure about the cause. Cutting the time down showed the same type of crash, but reliably.