Jason House wrote:
On Apr 15, 2009, at 6:50 PM, Michael Williams
wrote:
You can change the value all you want. You just can't change the key.
Right... That's the design in the google talk. Remi said he "can reuse
cache entries" and so avoids resizing / copying (greatly simplifying
the
I think your hash value is your first-try index into the hash table. So a 32-bit hash would be a 4E9 sized table. Probably too big for Remi's computer. I'd
guess that he's using something between 16 and 32 bits in his hash hey.
Jason House wrote:
On Apr 15, 2009, at 6:50 PM, Michael Willi
On Apr 15, 2009, at 6:50 PM, Michael Williams > wrote:
You can change the value all you want. You just can't change the key.
Right... That's the design in the google talk. Remi said he "can reuse
cache entries" and so avoids resizing / copying (greatly simplifying
the algorithm). I fin
You can change the value all you want. You just can't change the key.
Jason House wrote:
On Apr 14, 2009, at 7:57 PM, Rémi Coulom
wrote:
Jason House wrote:
Out of curiosity, how do you intelligently delete old nodes?
Reference counting won't always work due to cycles, and a nieve scan
of
On Apr 14, 2009, at 7:57 PM, Rémi Coulom
wrote:
Jason House wrote:
Out of curiosity, how do you intelligently delete old nodes?
Reference counting won't always work due to cycles, and a nieve
scan of the tree could block all threads.
I store a date of birth in every node. At the beginni
lockless hash table references.
essential.
On Mon, Apr 13, 2009 at 3:08 PM, Rémi Coulom wrote:
> Michael Williams wrote:
>>
>> What tricks are people doing to minimize the performance degradation due
>> to multiple threads contending for access to the tree (in MCTS)? Do you
>> only lock a portio
Jason House wrote:
Out of curiosity, how do you intelligently delete old nodes? Reference
counting won't always work due to cycles, and a nieve scan of the tree
could block all threads.
I store a date of birth in every node. At the beginning of a new search,
I increment time, and refresh the
On Apr 14, 2009, at 6:46 PM, Rémi Coulom
wrote:
Jason House wrote:
In my implementation, I found that node allocation is the most
difficult part. For a tree, I suppose it may be done easily by pre-
allocating a node pool for each thread, and managing memory
allocation locally.
I was
Jason House wrote:
In my implementation, I found that node allocation is the most
difficult part. For a tree, I suppose it may be done easily by
pre-allocating a node pool for each thread, and managing memory
allocation locally.
I was happy to hear recently that the D standard library will
Jason House wrote:
Also, you've commented previously about not resizing your table. If
you're using Cliff's algorithm, how do you clear tombstones? I assume
copying the table is nearly as much work as dynamic resizing. I
imagine in-place deletions could be done with the appropriate
barriers,
On Apr 14, 2009, at 5:42 AM, Rémi Coulom
wrote:
Jason House wrote:
I use atomic increments and atomic reads. It's really simple x86
assembly. To do that, I used to have a counter for wins and a total
simulations counter, but switched to wins and losses counter. Doing
that allows indepen
Jason House wrote:
I use atomic increments and atomic reads. It's really simple x86
assembly. To do that, I used to have a counter for wins and a total
simulations counter, but switched to wins and losses counter. Doing
that allows independent increments to those counters.
In my implementation,
I use atomic increments and atomic reads. It's really simple x86
assembly. To do that, I used to have a counter for wins and a total
simulations counter, but switched to wins and losses counter. Doing
that allows independent increments to those counters.
I have not done a lockless hashtable
I considered something similar. But instead of using a win count and a loss count, I use a win count and a simulation count. In that scenario, you would
update the simulation count immediately, and then maybe update the wincount once you know the result. But I haven't tried it either.
Álvar
I haven't implemented this successfully, so I probably shouldn't be
giving advice to anyone, but what I was trying to do when we stopped
developing dimwit was the following:
* When a thread enters a node of the UCT tree, increment the number
of losses (This will discourage other threads from enter
Michael Williams wrote:
What tricks are people doing to minimize the performance degradation
due to multiple threads contending for access to the tree (in MCTS)?
Do you only lock a portion of the tree? How would that work?
___
computer-go mailing l
16 matches
Mail list logo
