Rodent 1.7 is out

[carldaman]

Thanks a lot, Pawel!
Looking forward to testing it.

Regards,
CL

[Frank Quisinsky]

Hi Pawel,

at first, THANKS!

I hope you find out the time loses problems. On the other hand, perhaps each 100 games I have such a "lost on time" problem under Shredder Classic GUI. No problem for me to replay the games.

Now we have the versions from Dann Corbit (without POP) and your version. Unclear what I have to test, or should I wait a bit?

at second ...
I must test it a bit later. I have a lot to do in reorganisations of my rating list. I think I can test it middle of April.

Best
Frank

[PK]

First of all, thank You Dann for Your bugfixes! I have already merged them into my code and recompiled all the files. Also, the zip file on Rodent's webpage has been updated - 32-bit version now displays pv and both 64-bit versions are after profile guided optimization. So the official version is still on my page.

I have been asked for strength gain. It is rather modest. The code changes should yield something like +20 Elo, and there should be something more from pgo optimization. Anyhow, new Rodent is much slower, so quality of the compile becomes a bit more important than for the 1.6 version.

I also hope that time losses have finally gone away. They occured in the positions when the engine started a new iteration, finished it very quickly because of a draw detection or mate distance pruning or whatever of this kind, started another, the same pruning kicked in... It could have happen several times before 4096 nodes elapsed, and nodes-to-speed ratio in this scenario has been very skewed. right now Rodent checks for timeout also at the end of the iteration, irrespectively from node count. If anyone does any modifications to Sungorus, he should start from the very same fix, followed by Dann Corbit's range check fixes.

Also, I'd like You to play with creating the new personalities. I have just added another one to the pack (Solid). Current set of options probably allows more freedom than anything on the market, including good old Chessmaster series. I will probably run a little tournament for different personalities, if I get a couple of external entries.

Have fun!

[Dann Corbit]

First of all, thank You Dann for Your bugfixes! I have already merged them into my code and recompiled all the files. Also, the zip file on Rodent's webpage has been updated - 32-bit version now displays pv and both 64-bit versions are after profile guided optimization. So the official version is still on my page.

I have been asked for strength gain. It is rather modest. The code changes should yield something like +20 Elo, and there should be something more from pgo optimization. Anyhow, new Rodent is much slower, so quality of the compile becomes a bit more important than for the 1.6 version.

I also hope that time losses have finally gone away. They occured in the positions when the engine started a new iteration, finished it very quickly because of a draw detection or mate distance pruning or whatever of this kind, started another, the same pruning kicked in... It could have happen several times before 4096 nodes elapsed, and nodes-to-speed ratio in this scenario has been very skewed. right now Rodent checks for timeout also at the end of the iteration, irrespectively from node count. If anyone does any modifications to Sungorus, he should start from the very same fix, followed by Dann Corbit's range check fixes.

Also, I'd like You to play with creating the new personalities. I have just added another one to the pack (Solid). Current set of options probably allows more freedom than anything on the market, including good old Chessmaster series. I will probably run a little tournament for different personalities, if I get a couple of external entries.

Have fun!

You will still have time losses if the machine your engine plays happens to be running on a time that is modulo 49.x days (so about once every 50 days, if your engine is running at the wrong time of day on that day you will see time losses. Search the code base I provided for bugbug:drc and you will find it.

timer.c ( 152): return GetTickCount(); // bugbug:drc GetTickCount() wraps once every 50 days, causeing time control to go insane. Don't use this.

There are a few solutions.
1. Check for a working high resolution timer and use that if present and available (it is a limited resource).
2. Check the dll Kernel32.dll for the presence of GetTickCount64() and dynamically load that routine as a replacement for GetTickCount().
3. Use some other time API that does not wrap.

Using GetTickCount() is a guaranteed way to get losses on time, if you happen to be playing on the wrong day. Since the problem reoccurs every 50 days, if the tournament is played around the clock you have a surprisingly high probability of time failures.

[mar]

Hi Dann,
I think it's ok because he only uses it to measure delta time.
Those 49.7 days is simply the number of milliseconds in 2^32.
There are other issues with GetTickCount (granularity).
Also note the GetTickCount64 is not available on XP.

[mar]

Also note the GetTickCount64 is not available on XP.

Sorry, I see you address this in point 2, too late to edit my post...

[Dann Corbit]

Hi Dann,
I think it's ok because he only uses it to measure delta time.
Those 49.7 days is simply the number of milliseconds in 2^32.

DWORD start_time = GetTickCount(); // some huge number
DWORD sometime_later = GetTickCount(); // some small number
looks like we have not passed the elapsed time yet, even though we have.

There are other issues with GetTickCount (granularity).
Also note the GetTickCount64 is not available on XP.

[mar]

DWORD start_time = GetTickCount(); // some huge number
DWORD sometime_later = GetTickCount(); // some small number
looks like we have not passed the elapsed time yet, even though we have.

But the delta matches. Wrap for unsigned numbers is well defined.
2u - 0xfffffff0u = 18u (assuming 32-bit quantities).

There is a problem using signed integers though (I admit I do the same), where unsigned => signed conversion is probably UB for values >= 0x80000000u (signed=>unsigned is well defined).
So actually the problem (signed overflow) will occur after ~25 days, but (at least using msc) it still gives the expected result (but definitely UB):
-0x80000000 - 0x7fffffff = (signed overflow, wrap) = 1 (UB but works, assuming 2's complement representation).

[Charly]

Hi,

Perfect timing !

Many thnaks for this update ! Rodent 1.7 x64 is actually running on my "Fischer League" 3rd edition, just started one hour ago.

Results in 3 or 4 days ! Good luck !

regards.

Arnaud Loheac

[Charly]

Hi,

Perfect timing !

Many thnaks for this update ! Rodent 1.7 x64 is actually running on my "Fischer League" 3rd edition, just started one hour ago.

Results in 3 or 4 days ! Good luck !

Regards.

Arnaud Loheac