Author: Robert Hyatt
Date: 11:34:07 01/16/06
Go up one level in this thread
On January 16, 2006 at 13:57:42, Graham Banks wrote: >On January 16, 2006 at 11:20:56, Robert Hyatt wrote: > >>On January 16, 2006 at 00:43:10, Graham Banks wrote: >> >>>On January 16, 2006 at 00:20:04, Robert Hyatt wrote: >>> >>>>On January 15, 2006 at 21:34:32, Joshua Lee wrote: >>>> >>>>>Hello, >>>>>I wanted to know if anyone here is using more than 2GB for Hash Tables? >>>>>Is there a known limit for Chessbase programs? >>>>> >>>>>Does anyone know the most Memory for Hash Tables Crafty will use? >>>> >>>>whatever you have. On 32 bit machines, operating system limits often come into >>>>play, limiting total memory to 2 gigs. You can run this to 3 gigs if you work >>>>at it. on 64 bit systems, they can be huge... >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>thankyou >>> >>> >>>Is there not theoretically an optimum amount of hash for engines dependent upon >>>the time control used. >>>For example it would be disadvantageous to use too much hash at blitz time >>>controls whereas it would be disadvantageous to use too little at long time >>>controls? >>>That's my understanding, but some tell me that it's a contentious issue. >>>Hope I'm not opening a can of worms here! >>> >>>Graham. >> >>There are subtle issues. >> >>1. If an engine periodically stomps thru the hash table clearing everything, >>bigger hash takes longer to clear. In blitz games, it is possible that clearing >>the hash will take longer than the time alotted to do a quick search. Not good. >> :) >> >>2. Big hash causes TLB thrashing since TLBs have finite size and greatly speed >>up virtual-to-real address translations. For example, the typical PC can access >>memory in 150ns or less. So long as the TLB is able to provide virtual to real >>translations when asked to do so. Otherwise on the PC you throw in extra memory >>references to access the page tables to do this translation, and memory access >>time can climb. On an AMD opteron for example, a TLB miss can produce 4 extra >>memory accesses, which is a killer. The PC adds 1 or 2 extra accesses depending >>on the page size the O/S uses. That is also a killer. My Xeons have 60 TLB >>entries, the last opteron I used had 1024. So there are lots of variables to >>consider. >> >>One good plan is to look at the time control you are going to play. Then play >>about 10 moves of the game with hash size set to 2X and repeat. Once you >>increase the hash size and the program doesn't search any quicker (time to some >>particular move or depth is what you want to watch for) you know you have gone >>past the optimal hash size for that time control. Back up to the previous >>setting and that is optimal for this hardware and specific time control. >> >>Hope that helps... > > >Thanks Bob, > >very clearly explained. >I must admit I don't like blitz and therefore normally use longer time controls >such as 40 moves in 40 minutes, 40 in 80 or 40 in 120. >As my understanding is that you should never use more than half of your >available ram in total, that means I've usually given each engine 128mb hash >(total ram available being 768mb). >I've always found this to work well. > >Regards, Graham. The real issue is that A+B+C+D+E+F+G+H+...+Z must be less than the total size of your RAM. A, B, etc are program code, hash table(s), egtb caches, egtb indices, operating system itself, operating system buffers, necessary operating system tasks (Daemons on unix), etc. It is a tough thing to precisely quantify, so most end up on the conservative side of things because if you go over the RAM size, performance goes right in the tank... Note that testing a few positions and seeing "no disk I/O" is _not_ good enough. The EGTB decompression indices might easily get paged out of memory since there are no probes in the opening and early middlegame. But later, probes might start bringing 'em in, which will cause pieces of the hash table to leave memory, which starts the paging parade...
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.