Author: Mike Hood
Date: 15:30:11 05/05/04
Go up one level in this thread
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?
:)
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.