Author: Robert Hyatt
Date: 15:35:38 05/05/04
Go up one level in this thread
On May 05, 2004 at 18:30:11, Mike Hood wrote:
>On May 05, 2004 at 11:53:33, Robert Hyatt wrote:
>
>>On May 05, 2004 at 09:14:50, Mike Hood wrote:
>>
>>>On May 05, 2004 at 08:12:44, Vincent Diepeveen wrote:
>>>
>>>>On May 05, 2004 at 07:47:57, Mike Hood wrote:
>>>>
>>>>>I just let Filemon run while loading Fritz 8 to see why it takes so long. I was
>>>>>shocked to see that during the initialisation Fritz tries to open every possible
>>>>>tablebase. For instance...
>>>>>
>>>>>Open kpk.nbw.emd -- good, it's there
>>>>>Open kpknbw.emd -- file not found
>>>>>Open kpk_nbw.emd -- file not found
>>>>>Open kpk_nbw_emd -- file not found (I never knew this format was valid)
>>>>>Open kpk.nbw -- file not found
>>>>>
>>>>>And the same five accesses for the nbb file.
>>>>>
>>>>>Why carry on with the other three after finding the first tablebase? But it gets
>>>>>even wilder when it comes to the 6-piece tablebases. All 365 possible tablebase
>>>>>pairs in all possible formats are accessed, even though I don't have any on my
>>>>>disk. Thousands of "file not found" results. Just one example, to show how
>>>>>ludicrous it is:
>>>>>
>>>>>First Fritz tries to open krbnkp.nbw.emd, krbnkpnbw.emd, krbnkp_nbw.emd and
>>>>>krbnkp.nbw.emd. Almost the same as before, except Fritz is assuming 6-piece
>>>>>tablebases are compressed. But then Fritz tries to open krbnkp.0.nbw.emd,
>>>>>krbnkp.0_nbw.emd, krbnkp.0nbw.emd and krbnkp.0_nbw_emd. Then krbnkp.1.nbw.emd,
>>>>>etc... and krbnkp.2.nbw.emd... and all the way through to krbnkp.g.nbw.emd. That
>>>>>means 136 disk accesses for a tablebase that I don't have! And that's only one
>>>>>tablebase out of 365.
>>>>>
>>>>>Wouldn't it be much easier just to scan the tablebase directory and only open
>>>>>the files that actually exist?
>>>>
>>>>Both nalimov and i do this in a similar way.
>>>>
>>>>If you are willing to write code for this that works faster and works both for
>>>>windows and *nix, then i will be real happy to use it.
>>>>
>>>>Best Regards,
>>>>Vincent
>>>
>>>Thanks for the info, Vincent. I assumed the initialization code had been written
>>>by Chessbase, not by Eugene.
>>>
>>>My math was a bit off in my original post, but after looking at Filemon's log I
>>>can give the exact figure: Fritz attempts to access 33647 non-existent tablebase
>>>files. And please... you can't tell me that if the file krbnkp.0.nbw.emd doesn't
>>>exist it still makes sense to look for krbnkp.1.nbw.emd, krbnkp.2.nbw.emd, etc
>>>all the way to krbnkp.g.nbw.emd. That's a waste of processor time on any
>>>operating system.
>>
>>
>>Question is, how much time? The directory contents will be cached. No I/O at
>>all will be done. It probably won't take a second although you could test that
>>with a dinky program that tries to open 33K bogus filenames in the same
>>directory...
>>
>>sample:
>>
>>#include <sys/types.h>
>>#include <sys/stat.h>
>>#include <fcntl.h>
>>#include <string.h>
>>main() {
>> char fname[6];
>> int fd;
>> int i;
>> for (i=0;i<33000;i++);
>> sprintf(fname,"%d",i);
>> fd = open(fname,O_RDONLY);
>> if (fd > 0) {
>> write(fd,fname,strlen(fname));
>> close(fd);
>> }
>>}
>>
>>On my 2.8 xeon, here is how long it takes to run:
>>
>>
>>
>>crafty% time ./tstopen
>>0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 75pf+0w
>>
>>
>>essentially zero seconds.
>>
>>That isn't what is taking so long to open. It is actually opening and reading
>>the files that do exist, allocating memory for the decompression indices,
>>reading those in, etc...
>
>I accept your point, Bob. Reading existing files takes much more time than
>trying to open non-existent files, so the savings from optimizing the
>initialisation code might not be noticeable.
>
>Maybe my own programming background has corrupted me. I've worked 15 years
>programming car electronics, and I've had to optimize every last assembler
>command to avoid any delay in the fuel injection. If you're working with
>Windows, who cares about making software run faster? Whatever savings you make
>will be killed by the next operating system version.
>
>Or am I being too sarcastic?
>
>:)
I wouldn't disagree. I did lots of that kind of process-control stuff in the
past, and usually the vendor wanted to use a 2 dollar part when a 3 dollar part
would have made the programming much less time-critical...
But for opening files, it appears to be wasted effort. :)
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.