Author: Robert Hyatt
Date: 18:37:54 10/07/99
Go up one level in this thread
On October 07, 1999 at 19:10:08, Christophe Theron wrote: >On October 07, 1999 at 14:15:37, Robert Hyatt wrote: > >>On October 07, 1999 at 13:38:50, Ed Schröder wrote: >> >>>>Posted by Ratko V Tomic on October 07, 1999 at 08:22:04: >>>> >>>>> Every program needs to poll for input. Asking the keyboard / >>>>> mouse for input are expensive (slow) operations. In Rebel >>>>> I have a counter that makes sure to look for input after 500 >>>>> evaluations. If I decrease the value to say 50 or 10 the NPS >>>>> of Rebel drops tremendously (forgot about the exact slow-down). >>>> >>>>When I was looking for the cause of Rebel hangup in Windows DOS Box >>>>(and ended up writing that utility, fix.exe), I noticed that Rebel is >>>>taking mouse and keyboard interrupts in real time (I found mouse >>>>interrupt reentry was occasionally resulting in a lockup; the fix.exe >>>>TSR manages reentry of mouse interupt and precludes reentry). That >>>>would suggest Rebel need not do any polling at all, but it could >>>>handle all such tasks either within interrupt service or periodically >>>>based on the main timer interrupt (18.2 times/sec which is plenty >>>>responsevness for user input). Or an interrupt from mouse or kbd or >>>>system timer could redirect a function pointer for the call to evaluation >>>>to go through input processing (and then continue with the original call >>>>it intercepted), whenever there is input. Even the last option is faster >>>>than decrement+branch_on_0 combination which now occurs on every >>>>evaluation (if you're already calling using function pointers, there >>>>is no overhead at all, unless the input data has arrived). >>> >>>I could use the main timer interrupt indeed but I have chosen to be >>>in control myself for reasons of being as flexible as possible. One >>>day it might be needed to port Rebel and then I have one porting >>>problem less. >>> >>>The system I use comes from my 6502 days when I wrote chess >>>programs for the dedicated Mephisto series. Every prototype I >>>received had its own interrupt frequency (300, 600, 1200 you name >>>it) and needed specific hardware tuning because of that. >>> >>>My routine then simply blocked the 6502 interrupt (just a RETURN) >>>until my counter reached its value. >>> >>>>In any case, checking input every 500 evaluations, on a CPU doing >>>>150,000 nps means about 300 checks per second, which is about 10 >>>>times more checks than human perception needs. If you have an >>>>address of the variable (within the Rebel 10b &c executable) which >>>>contains this number 500, I would like to patch it to 5000 or more. >>>>This can be found with debugger, but it would be quicker if you have >>>>a number (e.g. from your MAP file produced by the linker). >>> >>>I have tried this and it gave me no speed-up. Actually the "500" number >>>I mentioned depends on the processor Rebel is running. On a fast PC >>>the number is much higher, on a slow 386SX-25 Mhz the number is "50" >>>which is (if I remember well the lowest value possible). >>> >>>I am still happy with the system. >>> >>>Ed >> >> >>I do this adaptively in Crafty. In longer games, I watch the nps, and use >>that to help me check for input once per second, _max_. In faster games, I try >>to poll at least 10 times during the expected move time, so that if the target >>time is 1 sec in a very fast game, I go for 1/10th of a second intervals. Ditto >>when the target = .1 seconds, I try for .01 seconds as the polling interval... >>just to control overhead while checking often enough to be reasonably close on >>the time limit.. > > >That's a smart system. In Tiger I have recently implemented a speed evaluation >logic which gives a number of nodes to compute between each call to the keyboard >(or mouse, or event) input. > >However it just tries to keep this call rate between 5 and 15 per second, >disregarding the time control. > >I have discovered on my K5 computer that calling the keyboard input too often >slows down the program considerably. Even in pure DOS (the Windows scheduling >algorithm has nothing to do with the problem). > >Under Windows it will kill you even more, because when the polling rate goes >above a given value, Windows simply considers your DOS box is idle and will >freeze it! > >This is something people should know. > > > Christophe If you were playing automatically on ICC you would see the problem with not checking real often. In 1 0 games (game in 1 minute) the target time can easily drop down to .1 seconds, or even .01 seconds after a hundred moves or so. You'd better check quickly there. :) This is a problem for windows crafty users (95/98, not so much NT it seems) as these systems seem to have a very inaccurate timing approach to life, making it very tough to move quickly enough, for reasons I don't understand (and don't want to understand). My favorite debugging test on my linux box is to play crafty vs crafty, 2 cpus per program, and play game in 1 second. Cool to watch as it _still_ looks like chess, just played impossibly fast. And I have had many games go over 100 moves...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.