Re: [computer-go] MoGo/professional challenge

2008-03-22 Thread Olivier Teytaud

It was 2 cores 2.6GHz. (intel core2 duo).


sorry, I believed it was the tipi.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


Re: [computer-go] Lockless hash table and other parallel search ideas

2008-03-22 Thread Olivier Teytaud

Hi,

I have got a lockless hash table to work, and I thought I'd share the 
results.

[...]


Great! For networks of 4-cores, it is not very useful,
but for highly smp machines it could be great - with your
grid5000 account, you might run crazystone on a
16-core machine and have a very impressive crazyStone.
Olivier

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


Re: [computer-go] Lockless hash table and other parallel search ideas

2008-03-22 Thread Rémi Coulom

Don Dailey wrote:

These are used in parallel chess programs, and it's very common.   A
pretty good article on this written by Hyatt (Crafty programmer and
author of former world computer chess champion Cray Blitz) and it's
called  A lock-less transposition table implementation for parallel
search chess engines, 


I see an on-line version of a similar article here:

 http://www.cis.uab.edu/hyatt/hashing.html


- Don
  


Hi Don,

Yes, I knew Bob's paper. In his approach, an entry will be lost in case 
of a collision. In my Go program, I never replace hash entries of the 
current search, because I have enough memory to store them all. I only 
have to be careful when allocating a node for the first time, so that 
two threads do not allocate the same slot. This happens rarely enough 
that the cost of a Test-And-Swap is negligible, so I prefer to do it 
that way. What I do is essentially the beginning of the Google talk I 
indicated yesterday, without resizing. I believe it is a lot cleaner 
than Bob's idea, although atomic increments are costly.


In fact, now that I think a little more about it, Bob's scheme would 
probably not work at all, because updating counters would mean updating 
the hash code, and any collision would cause a loss of the hash entry. 
It does not matter for alpha-beta, but losing an entry near the root in 
MC search would be very bad. Really ugly stuff would be necessary to 
repair the consequences of such a collision.


So, I believe Bob's idea would not work.

Rémi
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


Re: [computer-go] Lockless hash table and other parallel search ideas

2008-03-22 Thread Don Dailey
I'll take a look at the references you posted - they look pretty
interesting from an initial glance at them.

- Don


Rémi Coulom wrote:
 Don Dailey wrote:
 These are used in parallel chess programs, and it's very common.   A
 pretty good article on this written by Hyatt (Crafty programmer and
 author of former world computer chess champion Cray Blitz) and it's
 called  A lock-less transposition table implementation for parallel
 search chess engines,
 I see an on-line version of a similar article here:

  http://www.cis.uab.edu/hyatt/hashing.html


 - Don
   

 Hi Don,

 Yes, I knew Bob's paper. In his approach, an entry will be lost in
 case of a collision. In my Go program, I never replace hash entries of
 the current search, because I have enough memory to store them all. I
 only have to be careful when allocating a node for the first time, so
 that two threads do not allocate the same slot. This happens rarely
 enough that the cost of a Test-And-Swap is negligible, so I prefer to
 do it that way. What I do is essentially the beginning of the Google
 talk I indicated yesterday, without resizing. I believe it is a lot
 cleaner than Bob's idea, although atomic increments are costly.

 In fact, now that I think a little more about it, Bob's scheme would
 probably not work at all, because updating counters would mean
 updating the hash code, and any collision would cause a loss of the
 hash entry. It does not matter for alpha-beta, but losing an entry
 near the root in MC search would be very bad. Really ugly stuff would
 be necessary to repair the consequences of such a collision.

 So, I believe Bob's idea would not work.

 Rémi
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


[computer-go] 9x9 CGOS

2008-03-22 Thread Christoph Birk

 http://cgos.boardspace.net/9x9/standings.html
is not updating.

Christoph

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


Re: [computer-go] 9x9 CGOS

2008-03-22 Thread Don Dailey
I just gave it a kick - within about 15 minutes or so the server will
restart and this should start updating.

I won't be around to babysit it, but it should be ok.

- Don


Christoph Birk wrote:
  http://cgos.boardspace.net/9x9/standings.html
 is not updating.

 Christoph

 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


[computer-go] 9x9

2008-03-22 Thread steve uurtamo
congratulations to mogo on its performance today!

it was an excellent result (1-2) versus a professional,

s.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/