Author: James Robertson
Date: 09:22:12 06/23/99
Go up one level in this thread
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
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.