Author: Robert Hyatt
Date: 05:54:32 06/23/99
Go up one level in this thread
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...
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.