Author: Marc Bourzutschky
Date: 10:25:18 05/05/04
Go up one level in this thread
On May 05, 2004 at 11:55:07, Robert Hyatt wrote: >On May 05, 2004 at 09:37:14, Marc Bourzutschky 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. >> >>As this is only done once during initialization it is not such a big deal. IMHO >>a more serious nuisance is that all available endgames on the paths are >>initialized even though they may never be used. As a fair amount of memory is >>taken up by each endgame that is initialized this is a serious inefficiency. >>I'm surprised that Fritz and Co. have not implemented a scheme where an endgame >>is only initialized when it is actually required. >> >>-Marc > > >Would you _really_ want to wait until you have a few seconds left, with no >increment, then start opening files, malloc()'ing buffers, setting up the >decompression stuff? Oops. flag just fell. > >:) I actually do just that and it takes a small fraction of a second to initialize one tablebase. For me at least the likelyhood of this being an issue is miniscule compared to the amount of memory I can save.
This page took 0.01 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.