Author: Robert Hyatt
Date: 10:55:49 03/10/04
Go up one level in this thread
On March 09, 2004 at 16:43:19, David Mitchell wrote: >On March 09, 2004 at 11:30:44, William Penn wrote: > >>On March 09, 2004 at 05:28:30, Albert Bertilsson wrote: >> >>>I'd just like to make one thing clear, the "churning" of the harddrive(s) is >>>there because of the usage of tablebases. There is nothing that can solve this, >>>having larger cache for tablebases help very little because the tablebases are >>>so huge and you computer search very fast. Using faster drives (like scsi) will >>>increase performance because of faster tablebase access times, but the drives >>>will be working constantly at peek anyway. Turn of tablebases or get used to >>>drive "churning", that is you options. >> >>There is another option! Reduce hash table size. Then the engine speed returns >>to near normal. True, it doesn't seem to affect the churning, but the engine >>then runs at near normal speed - which is an important improvement. >> >>>Using tablesbases give you perfect solutions to some positions but the obvious >>>trade of is nps, I guess that many systems don't benefit very much from >>>tablebases due to the reduced search speed. >> >>Again, reducing hash table size tends to keep nps near normal speed, in my >>experience with a souped-up Compaq Presario/XP 2400+/1G RAM running Windows XP >>Home. I imagine that most systems can use tablebases OK if that is done. The >>problem is that most people want to use as big a hash size as possible, but that >>incorrect when the endgame approaches and tablebase access starts to be >>significant - reducing the engine speed greatly. >> >>>If you get a lot of harddrive noise you could try mounting your drive in some >>>rubber bands instead of directly in the chassi to reduce the noise a little. >> >>I'm not concerned about the noise. My Maxtor drives have a "quiet" mode >>available if I want to use it. But it slows down access somewhat, and the noise >>is also a good indicator of what the drive is doing, so I don't mind the little >>extra noise. >> >>>/Albert >> >>Overall, you should be aware that such extreme hard drive churning will reduce >>the lifetime of the drive significantly. Hard drives have a finite lifetime, and >>can only seek so many times before the heads wear out eventually. Those who >>write the code for chess tablebase access should keep this in mind, and do >>whatever is necessary to improve it, and reduce the hard drive churning as much >>as possible. There is really not much point to adding 6-man tablebases to most >>ordinary computer systems until this churning problem is solved. >>WP > >Good point about adjusting your hash table size for best engine performance in >Windows. > >Hard drive heads however, ride on a stream of air produced by the rapidly >spinning disk platter. Minus dirt and dust collisions with suspended particles >in the air, not much "wearing" going on. The levers that move the head are >another matter. > >Back in the somewhat early DOS days, some IDE controller cards (the IDE >functions were not on the mobo at that time), actually had memory slots you >could fill as a HD cache. Paradise was one brand I recall. > >If you had to access the HD a lot, having several extra MB as a hard drive cache >was a big speed up. Very nice! > >Possibly something like that could be done today, replacing the drive card/OS HD >cache memory with something _really_ big. That would not stop all the disk >activity, but it would certainly help speed up TB access, and save a lot of disk >activity, too. > >Probably wouldn't be worth it for the occassional user, but for a tournament >computer, it'd be worth it. > >dave simple solution is already available. Hardware raid-0. "stripes" the data across multiple disks. 4 drives make read/write 4x faster as all 4 drives get read/written in parallel. Then add 1 gb or more of RAM to the raid controller and there's your big cache. Fast as all hell...
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.