Laskos wrote:Pal, something is wrong. Rybka cannot have + 274 = 231 - 95 against latest IvanHoe. Did you check NPS, time used, losses on time or illegal moves?
Kai
I guess that at least 1/3 of the losses are losses on time.
In the given PGN I count a lot of time losses by Ivanhoe:
139 against Houdini
137 against Rybka
110 against Stockfish
101 against Critter
487 TOTAL
The other engines have few time losses only:
Houdini 29 TOTAL
Rybka 18 TOTAL (9 against Ivanhoe)
Stockfish 13 TOTAL
Critter 10 TOTAL
There were also 103 games that ended by draw on time (19 between Rybka and Ivanhoe). After subtracting all "loss/draw on time" games the outcome between Rybka and Ivanhoe turns into:
Rybka 4.1 - Ivanhoe B47cB +137 =212 -86
I can't say whether this is in the expected range, though, for that time control. Due to the abnormally high number of time losses by Ivanhoe (487 in 2400 games = about 20%) I would not trust the whole result (of Ivanhoe at least) too much in this test.
Laskos wrote:Pal, something is wrong. Rybka cannot have + 274 = 231 - 95 against latest IvanHoe. Did you check NPS, time used, losses on time or illegal moves?
Kai
I guess that at least 1/3 of the losses are losses on time.
In the given PGN I count a lot of time losses by Ivanhoe:
139 against Houdini
137 against Rybka
110 against Stockfish
101 against Critter
487 TOTAL
The other engines have few time losses only:
Houdini 29 TOTAL
Rybka 18 TOTAL (9 against Ivanhoe)
Stockfish 13 TOTAL
Critter 10 TOTAL
There were also 103 games that ended by draw on time (19 between Rybka and Ivanhoe). After subtracting all "loss/draw on time" games the outcome between Rybka and Ivanhoe turns into:
Rybka 4.1 - Ivanhoe B47cB +137 =212 -86
I can't say whether this is in the expected range, though, for that time control. Due to the abnormally high number of time losses by Ivanhoe (487 in 2400 games = about 20%) I would not trust the whole result (of Ivanhoe at least) too much in this test.
Sven
Depends on how you look at it. That is the result for IvanHoe at this speed. If and when they fix the time control bug (reported by me some months ago) then there will be a different result for the same time controls.
Those were my thoughts too Dann. I noticed the many losses on time by Ivan, but since the others did not suffer the same, then it is a problem that should show in the results.
@Sven - Thanks for counting the time losses; I did not know it was THAT bad for Ivan.
I agree Ferdinand. Of course the games will not be as "high quality" as the slower games, but several of the developers seem to use these super-fast games to test their improvements.
Kind of interesting too that they seem to fall into roughly the same ranking as at the longer times (excluding the large number of time-losses by Ivan in this match).
PawnStormZ wrote: I agree Ferdinand. Of course the games will not be as "high quality" as the slower games, but several of the developers seem to use these super-fast games to test their improvements.
Kind of interesting too that they seem to fall into roughly the same ranking as at the longer times (excluding the large number of time-losses by Ivan in this match).
Use LittleBlitzer, with (N_cores - 1) simultaneous games of 1core engines on your N_cores machine. At even shorter TC (say 1s + 0.1s) almost all strong UCI engines are stable (very few time losses, if at all).
So you think it was the GUI that caused the losses on time? I will take a look at the LittleBlitzer that you mentioned.
ChessGUI does have a feature called "lag-free timing" which I have not tried. I think that is supposed to eliminate any time taken away from the engine by the GUI. I will have to try that (maybe Ivan against Rybka) and see if it makes any difference.
I guess in theory there should never be any losses on time as long as an increment is used; since the cpu is so fast, even 100th of a second should probably be enough.
So you think it was the GUI that caused the losses on time? I will take a look at the LittleBlitzer that you mentioned.
ChessGUI does have a feature called "lag-free timing" which I have not tried. I think that is supposed to eliminate any time taken away from the engine by the GUI. I will have to try that (maybe Ivan against Rybka) and see if it makes any difference.
I guess in theory there should never be any losses on time as long as an increment is used; since the cpu is so fast, even 100th of a second should probably be enough.
I guess that 50ms increment is the minimum, for example 500ms basis + 50ms increment. I didn't try ChessGUI, for now all my testing is with LittleBlitzer. I think one should not test on all his cores at these time controls.
I let Rybka and Ivanhoe play another 600 games under the same conditions---except that I used the "lag-free timing" option in the ChessGUI. This makes sure that the engines are not "cheated" out of any time by the GUI, and maybe the system too. There were 0 losses on time in the 600 games.
Contrary to what people are expecting, Rybka still won the match! It seems that the newest version of Rybka plays the super-fast time controls very well indeed.
