"Euc1id" wrote in rec.games.chess.computer:

I noticed that Shredder 7.04 UCI takes a long time to load with
Windows XP. I didn't know why, but I do now... Tablebases.



It might be a good idea to check the integrity of your tablebases. A very
simple way to do it is downloading Wilhelm from Rafael Andrist
http://www.geocities.com/rba_schach2000/
(which even can check 6 men)
and use the tablebase checker to see if they're all sound and safe.

It's well known that Fritz and friends even can refuse to _start_ with a
corrupt tablebase installed.

Another option is reducing your HT size to prevent disk swapping and
increasing your endgame hash a bit. You can reduce hash table inside the
program, you can edit the Nalimov cache in the Chssbase.ini-file in your
windows directory. You could try to change it to 16 Mb if it's set at its
standard 4 Mb.

--
CeeBee


Uxbridge: "By God, sir, I've lost my leg!"
Wellington: "By God, sir, so you have!"


Google CeeBee @ www.geocities.com/ceebee_2

Euc1id wrote:

If I disable the tablebases, it loads quickly, in a few seconds. But with
the tablebases active, it takes 2-3 minutes to load. The same when shutting
down the GUI (exiting the Shredder 7 CB GUI). If the tablebases were active,
it may take a long time to shut down, perhaps 5-10 minutes!

That's definitely odd. There's nothing there that needs to be saved to disk.
If you have a *huge* tb cache that gets swapped out, perhaps. Don't know
Shredder, so I don't know what kind of configuration options you have here.

Check the page file usage while running -- ctrl-alt-del, and select performance.
Or use the MMC Performance monitor (perfmon.msc), particularly as regards memory,
paging and swapping.

--
Anders Thulin http://www.algonet.se/~ath

CeeBee wrote in message . 6.84...
It might be a good idea to check the integrity of your tablebases. A very
simple way to do it is downloading Wilhelm from Rafael Andrist
http://www.geocities.com/rba_schach2000/
(which even can check 6 men)
and use the tablebase checker to see if they're all sound and safe.

CeeBee,

I have the same problem as described by Euclid with my Shredder 7.04
and Windows XP.

I went to Rafael Andrist website but it's in German. I don't know what
to download. Is there an English website to go to?

Thanks, Lance

CeeBee wrote in message . 6.84...

Halfway the page it says:

Download (Version 1.43, 9. Februar 2003): Wilhelm.zip (2.82 MB);

I guess that's Eglish enough to know

OK, I'll try that.

The slow down of Shredder, with the tablebases, has to also with a
high hash table. I put mine to a maximum of 381 Mb, when I changed it
to 200, it went faster to initialize and to turn off.

Thanks, Lance

Thanks guys for the tips...

I downloaded Wilhelm's program but couldn't get it to install. I gave up
because I couldn't understand all of the popups in German. However I've
checked my tablebases with a MD5 sum utility which verified OK.

I've found one workaround which helps. If I load the Fritz 5.32 engine
before I shut down the Shredder 7 GUI, it shuts down much faster. Then it
also loads faster when I restart it. That saves considerable time overall.
Setting hash to 1MB and tablebase cache to 1MB may also help. Admittedly my
new 128MB Windows XP Home box could use more memory - just had it a few
days - but I doubt that would fix the problem. In my experience adding more
memory does not speed up a computer. If there's a slowdown problem, it
probably has another cause.

I'm finding various severe slowdowns with Windows XP related to compressed
files, and of course tablebases are compressed files. For example the Disk
Cleanup utility won't work unless you delete a line in the registry that
relates to reading inside compressed files:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\Volum
eCaches\Compress old files]
@="{B50F5260-0C21-11D2-AB56-00A0C9082678}"
"Priority"=dword:0000012c
It may also help to unregister "zipfldr.dll" to prevent the search operation
from looking inside compressed files:
regsvr32 c:\winnt\\system32\zipfldr.dll /u
(leave off the /u to reregister it)

Etc.
Euc1id


Liam Too" wrote in message
om...
CeeBee wrote in message
. 6.84...

Halfway the page it says:

Download (Version 1.43, 9. Februar 2003): Wilhelm.zip (2.82 MB);

I guess that's Eglish enough to know

OK, I'll try that.

The slow down of Shredder, with the tablebases, has to also with a
high hash table. I put mine to a maximum of 381 Mb, when I changed it
to 200, it went faster to initialize and to turn off.

Thanks, Lance

I think it's obvious that my paging file is severely overworked and causing
the slowdown, because my hard drive light is almost constantly blinking. It
just can't spare much time to perform ordinary tasks! But I don't know
anything more to do about it. I've tried tweaking the registry per advice
from an expert in that regard, but it didn't do much. I can add more RAM but
doubt that will fix it.

As I mentioned in my comments in the other branch of this thread, I believe
it has something to do with the peculiar treatment of compressed files by
Windows XP. It may be trying to read inside all of them it encounters,
whether or not that's necessary for the primary task it's supposed to be
performing!?
Euc1id

"Anders Thulin" wrote in message
...


Euc1id wrote:

If I disable the tablebases, it loads quickly, in a few seconds. But
with
the tablebases active, it takes 2-3 minutes to load. The same when
shutting
down the GUI (exiting the Shredder 7 CB GUI). If the tablebases were
active,
it may take a long time to shut down, perhaps 5-10 minutes!

That's definitely odd. There's nothing there that needs to be saved to
disk.
If you have a *huge* tb cache that gets swapped out, perhaps. Don't know
Shredder, so I don't know what kind of configuration options you have
here.

Check the page file usage while running -- ctrl-alt-del, and select
performance.
Or use the MMC Performance monitor (perfmon.msc), particularly as regards
memory,
paging and swapping.

--
Anders Thulin http://www.algonet.se/~ath

Euc1id wrote:
I think it's obvious that my paging file is severely overworked and causing
the slowdown, because my hard drive light is almost constantly blinking.

I suggest you use a slightly more advanced technique that that to diagnose
your problem. Watching das blinkenlights only tells you the disk is being used,
but it doesn't tell you why. The Windows Task Manager is a far more
reliable tool to use.

As I mentioned in my comments in the other branch of this thread, I believe
it has something to do with the peculiar treatment of compressed files by
Windows XP. It may be trying to read inside all of them it encounters,
whether or not that's necessary for the primary task it's supposed to be
performing!?

And how are you going to verify this hypothesis? Does it help you formulate
any approach to improving the situation?

Don't confuse the compressed files that are used by Windows XP with
application-specific compressed files. And don't confuse Windows innate
knowledge of .ZIP archives with the totally unrelated compression method
used for the Nalimov endgames.

Unless of course you have asked windows to place the .emd files
inside .ZIP archives, which would be most unwise. In such a case,
you *will* have Windows decompressing the *entire* .ZIP archive
before it can do anything else with that particular file.
As the second compress is not likely to squeeze very much out
of the .emd files, though it is sure to add quite a lot of
compute and storage overhead. It's a no-win situation.

Let the Nalimov files stay as they are -- don't try to add any further
compression in case you have done so.

Having Windows compress the .emd files by its ordinary file
system compression (Properties / Advanced / Compress)would be less
inefficient as to time, but would probably not produce any worthwile
decrease in file size either.

--
Anders Thulin http://www.algonet.se/~ath

"Euc1id" wrote in rec.games.chess.computer:

I downloaded Wilhelm's program but couldn't get it to install. I gave
up because I couldn't understand all of the popups in German. However
I've checked my tablebases with a MD5 sum utility which verified OK.

Wilhelm of course does the same be it in a GUI.


Admittedly my new 128MB Windows XP Home box could use more memory -
just had it a few days - but I doubt that would fix the problem. In my
experience adding more memory does not speed up a computer. If there's
a slowdown problem, it probably has another cause.


Recently a test showed that a considerable speed gain occured with XP when
adding memory up to 512 Mb; after that the speed gain was negligable.

My own experience as well is that an increase of memory speeds up the PC
substantially, with all Windows OS's I had the bad luck to run into, and
especially with a memory usurper like Windows XP.

--
CeeBee


Uxbridge: "By God, sir, I've lost my leg!"
Wellington: "By God, sir, so you have!"


Google CeeBee @ www.geocities.com/ceebee_2