Author: Andrew
Date: 10:37:25 06/23/99
Go up one level in this thread
On June 23, 1999 at 12:22:12, James Robertson wrote: >On June 23, 1999 at 08:54:32, Robert Hyatt wrote: > >>On June 23, 1999 at 00:26:18, Alex Boby wrote: >> >>>On June 22, 1999 at 22:14:08, Robert Hyatt wrote: >>> >>>>On June 22, 1999 at 15:18:17, Alex Boby wrote: >>>> >>>>> >>>>>A couple problems with timing... >>>>> >>>>>1. In my limited spare time I've just done the switch over from depth based to >>>>>time based searching. I am now having difficulties coming up with an algorithm >>>>>to choose the amount of time which should be spent searching for each move. This >>>>>is a trivial task if the time controls are x moves in y minutes but if the time >>>>>controls are simply x minutes for the whole game (like on ICS), then what's the >>>>>most efficient way to use the time? >>>> >>>> >>>>use target=time_left/X, where X is a constant of your choice. 25-30 work >>>>pretty good, which gives a steadily decreasing time per move as time is >>>>burned away... But experiment with X until _you_ are happy with the usage >>>>pattern... >>>> >>> >>> Sounds like a simple yet effective idea. Is there any advantage to using more >>>time in the opening as opposed to the endgame? I was thinking that some kind of >>>more steady approach would be better, or if anything, probably more time should >>>be spent in the middle game. Perhaps I could use some kind of dynamic X? Ahh,.. >>>now I'm just thinking out loud again :). >>> >>>> >>>> >>>>> >>>>>2. I am developing in C under linux and using the clock() command for all >>>>>timings. The problem I have is that when it says that it took, for example, 10 >>>>>seconds to search, it's in actuality more like 25 seconds. At first I thought >>>>>that I had some kind of problem with casting or arithmetic but I checked all >>>>>that. I also examined crafty's code and it seems exactly the same as far as >>>>>usage of clock() is concerned. Then I thought that maybe my clock chip was >>>>>malfunctioning, but if this were the case then my system would not be keeping >>>>>accurate time,... but it is. Therefore I have no idea what the problem could be, >>>>>but it's a pretty significant one as far as I'm concerned. Any ideas? >>>>> >>>>>Much thanks, >>>>>Alex Boby >>>> >>>> >>>> >>>> >>>>There are _two_ times under unix. clock() returns the total cpu time used. >>>>gettimeofday() is used to return wall-clock time, which is more important in >>>>chess. In general, cpu and wall-clock times should step along together unless >>>>your machine is doing more than one computational task... or unless your >>>>program is doing a lot of I/O for some reason... >>> >>> >>> Just 'show thinking' kind of stuff for debugging purposes. I guess clock() is >>>more a profiling tool then and gettimeofday() is used for more practical >>>purposes. >>> >>> btw,.. your paper on book learning in a recent ICCA journal was very >>>informative and interesting for me. I thank you for taking the time and effort. >>> >>>Alex Boby >> >> >>There are others planned as I have time... one almost finished in fact... >> >>on the time front one good idea is to compute >> >>cpu = clock() time / gettimeofday() time all * 100 >> >>which should come out to 100 every time... that represents the percentage of >>the cpu your program got while thinking. If it isn't 100%, you are doing I/O, >>paging, or something else is running... > >How would you do this in Windows? > >James GetThreadTimes() vs GetTickCount() does the trick in windoze. One bad news: GetThreadTimes tells us nothing about other threads running... -Andrew-
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.