Author: Robert Hyatt
Date: 19:02:13 04/30/04
Go up one level in this thread
On April 30, 2004 at 16:56:10, Vincent Diepeveen wrote: >On April 30, 2004 at 16:49:54, Robert Hyatt wrote: > >>On April 30, 2004 at 16:25:29, Eugene Nalimov wrote: >> >>>On April 30, 2004 at 16:24:39, Robert Hyatt wrote: >>> >>>>On April 30, 2004 at 14:42:29, Vincent Diepeveen wrote: >>>> >>>>>On April 30, 2004 at 13:44:17, Ingo Bauer wrote: >>>>> >>>>>>On April 30, 2004 at 13:36:44, Ingo Bauer wrote: >>>>>> >>>>>>>On April 30, 2004 at 09:53:01, Karl-Johan Olsen wrote: >>>>>>> >>>>>>>>btw. it's in the classical interface... >>>>>>> >>>>>>>Hi >>>>>>> >>>>>>>I never checked this and can't at the moment (will later) but it is completly >>>>>>>useless. 64 is more than enough, let the OS do the caching job! >>>>>>> >>>>>>>Bye >>>>>>>Ingo >>>>>> >>>>>>OK, I could not wait: >>>>>> >>>>>>CPU0: AuthenticAMD x86 Family 6 Model 10 Stepping 0 2505 MHz >>>>>>GUI: Tablebases with 5 pieces found! [Cache: 999 MB + internal 13.67 MB] >>>>>>Engine: Shredder 8 (64 MB) >>>>>>by Stefan Meyer-Kahlen >>>>>> 4/04 0:00 +M11 1.Ne6 Rg6 (95) 5 >>>>>>best move: Nc7-e6 time: 0:00.016 min n/s: 7.687 CPU 93.7% n/s(1CPU): 8.203 >>>>>>nodes: 123 TB: 174 >>>>>> >>>>>>There seems to be a limitation of 999 MB for the TBs Cache, and the 5 Pcs at >>>>>>least are working fine. But again 999 is completly useless! The OS is doing the >>>>>>caching job allready. Use a bit more for Engine-Hash and let 100-200 MB Memory >>>>>>free for the OS. Done! >>>>>> >>>>>>Ingo >>>>>> >>>>>>Ingo >>>>> >>>>>The OS might cache it Ingo, but won't decompress it for you which also takes >>>>>quite some time. A bigger EGTB cache works better than letting the OS find the >>>>>golden coins. >>>>> >>>>>Best regards, >>>>>Vincent >>>> >>>>Current egtb cache caches compressed blocks. So this is a moot point. >>> >>>Unfortunately no. That is in my "TODO" list. >>> >>>Thanks, >>>Eugene >> >>So you are caching decompressed stuff? IE a buffer to read into, then >>decompress into the cache??? However, the original point is still valid, that >>this is not a big issue. Decompression compared to I/O is tiny. > >Unfortunately no. Unfortunately, no, what? I/O time is _way_ slower than decompression. Otherwise it would be more efficient to use non-compressed tables. I have tried it both ways. Compressed is faster, period. > >>> >>>>Decompression is _not_ the bottleneck. From actual testing rather than >>>>guessing...
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.