Author: Christophe Theron
Date: 16:10:08 10/07/99
Go up one level in this thread
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
This page took 0.01 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.