Author: Robert Hyatt
Date: 20:07:20 08/27/99
Go up one level in this thread
On August 27, 1999 at 17:51:53, KarinsDad wrote: >On August 27, 1999 at 16:09:21, Robert Hyatt wrote: > >[snip] >> >> >>Not to mention the fact that you have to have a hash table big enough so that >>entries don't get overwritten? My xeon has 512mb, but that isn't _near_ enough >>to guarantee that I can keep everything... >> >>Sounds like overkill that will really slow you down, for minimal gain... but >>it is worth experimenting with... > > >I agree. But, I'm trying it none the less. My experiments have shown that the >parent links are really helpful. The child links, much less so. > >But, even if I get 100,000 nodes per second, 240 seconds for a 4 minute search, >and 128 bytes per "extended sized node", I would have to have a hash table size >of about 3 GB if I wanted to save every node. So, with about a 100 MB hash >table, I can only hang onto about 3% of the nodes. So, I have to find a way to >remove 97% of the nodes. Even if I could drop this down to 80 bytes or so, I >would still have to get rid of 95% of the nodes, so the space issue does not >seem to be a major factor here. I do have a lot of stuff in my hash nodes which >I could probably do in another way, but for now, the extra 40 bytes or so due to >the links per node do not seem to be the critical factor (yet). And, even if I >drop the child nodes completely (these are easy to remove, the parent nodes >though are critical to my current search/hash design), this would only save >about 20 bytes or so on average. > >KarinsDad :) if your math is right, doesn't that mean that 95% or more of your tree is not 'linked'??? ie how does the parent/child pointers work if you can only store 3% of the tree in the first place???
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.