Re: [Computer-go] Playout speed... again

[Urban Hafner]

Very nice speed up Goncalo! This prompted me to check my playout speed and
with the recent addition of 3x3 patterns I'm now down to 6pps on 19x19.
Whoops! ;) I may need to do some optimisations ...

Urban

On Fri, Oct 16, 2015 at 1:09 AM, Gonçalo Mendes Ferreira 
wrote:

> Thanks everyone for your responses. This is followup after implementing
> Dusty Leary's  very complete suggestion.
>
> My program is now running 547 playouts/sec and thread, but a lot of
> optimizations were removed so I'm sure there's space for growth here. It is
> now spending 75% of the time in the selection of the play itself by
> probability distribution. The patterns were simplified to not needing
> actual liberty/capture counts.
>
> I'm also considering the whole board for pattern matching only about 1/4
> of the time, like Petr suggested; simplified ko detection, hardcoded some
> patterns, cached all matchable pattern configurations at startup (that's
> 351882 from just 13 base patterns from GNU Go's montegnu_classic), etc.
>
> As for more complete heuristics, my UCT search does have itself some very
> heavy heuristics and needs real liberty counts, but I need faster playouts
> before feeling the impact of the UCT states initialization.
>
> Big thanks to Dusty for the structure explanation. I had already thought
> of something similar but never tested it because group captures seemed too
> heavy. I was wrong since the real cost is in testing atari/counting
> liberties.
>
> Thanks again,
> Gonçalo
>
>
> On 15/10/2015 10:30, Petr Baudis wrote:
>
>> On Wed, Oct 14, 2015 at 06:00:56PM -0700, Dusty Leary wrote:
>>
>>> The trick to avoid recursively counting liberties:
>>> Track the liberties for a group/chain using a simplified data structure
>>> that looks like struct ChainLibertyInfo { int liberty_count; int
>>> liberty_sum; int liberty_sum_squares; }
>>>
>>> The interesting thing about this data structure is that it's a Set which
>>> can answer the isInAtari() query and the getAtariPoint() query, without
>>> having to track a lot of data.  But it doesn't support enumerating all
>>> the
>>> liberties.
>>>
>>This is a nice trick I once implemented too.  But for any kind of
>> interesting tactical evaluation (which is an important ingredient for
>> a strong program), you end up needing to be able to enumerate at least
>> two liberties, ideally even three.  Then, you can't use this trick.
>>
>>
>>In Pachi, I got inspired by GNUGo and track liberties only up to
>> N liberties (N=5 I think).  Any group with more than N is regarded
>> as having N libs.  This cuts off a lot of overhead, IIRC it helped
>> me a lot.
>>
>>If you are doing probability distribution stuff, I think a popular
>> trick is first deciding whether you are going to look just in last move
>> neighborhood or tenuki; most of the time, your roll will go with the
>> last move neighborhood and you won't need to spend a lot of time going
>> through the whole board.
>>
>>In general, you may simply want to look at how other programs do
>> things...  There's plenty of fast open source stuff out there.
>>
>>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>



-- 
Blog: http://bettong.net/
Twitter: https://twitter.com/ujh
Homepage: http://www.urbanhafner.com/
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Lucas, Simon M]

Did I read that correctly?  The number of playouts per second
for Many Faces has gone DOWN by a factor of 10?  (25,000 -> 2,500)
Presumably do to the playouts being heavier.

Simon


-Original Message-
From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf Of 
David Fotland
Sent: 15 October 2015 06:51
To: computer-go@computer-go.org
Subject: Re: [Computer-go] Playout speed... again

In 2008 Many Faces was getting about 25k light playouts per second on 19x19.  
Today it gets 2500 playouts per second on one thread of an i7-3770.  I don’t 
use a probability distribution in the UCT tree.  I both count liberties and 
maintain lists of liberty points, but all incrementally.  In the playouts I use 
3x3 patterns with gammas like Crazystone, not just the Mogo patterns, but I 
only do a partial distribution.  I also do local ladder searches and many other 
local tactics things.

David

> -Original Message-
> From: Computer-go [mailto:computer-go-boun...@computer-go.org] On 
> Behalf Of Gonçalo Mendes Ferreira
> Sent: Wednesday, October 14, 2015 3:27 PM
> To: [mailing list] Computer Go
> Subject: [Computer-go] Playout speed... again
> 
> Hi, I've been searching the mailing list archive but can't find an 
> answer to this.
> 
> What is currently the number of playouts per thread per second that 
> the best programs can do, without using the GPU?
> 
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My 
> heavy playouts use MoGo like patterns and are probability distributed, 
> with liberty/capture counts/etc only updated when needed, so it should 
> be pretty efficient.
> 
> What would be a good ballpark for this?
> 
> Thank you,
> Gon alo F.
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go

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

Re: [Computer-go] Playout speed... again

[Petr Baudis]

On Wed, Oct 14, 2015 at 06:00:56PM -0700, Dusty Leary wrote:
> The trick to avoid recursively counting liberties:
> Track the liberties for a group/chain using a simplified data structure
> that looks like struct ChainLibertyInfo { int liberty_count; int
> liberty_sum; int liberty_sum_squares; }
> 
> The interesting thing about this data structure is that it's a Set which
> can answer the isInAtari() query and the getAtariPoint() query, without
> having to track a lot of data.  But it doesn't support enumerating all the
> liberties.

  This is a nice trick I once implemented too.  But for any kind of
interesting tactical evaluation (which is an important ingredient for
a strong program), you end up needing to be able to enumerate at least
two liberties, ideally even three.  Then, you can't use this trick.


  In Pachi, I got inspired by GNUGo and track liberties only up to
N liberties (N=5 I think).  Any group with more than N is regarded
as having N libs.  This cuts off a lot of overhead, IIRC it helped
me a lot.

  If you are doing probability distribution stuff, I think a popular
trick is first deciding whether you are going to look just in last move
neighborhood or tenuki; most of the time, your roll will go with the
last move neighborhood and you won't need to spend a lot of time going
through the whole board.

  In general, you may simply want to look at how other programs do
things...  There's plenty of fast open source stuff out there.

-- 
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

Thanks everyone for your responses. This is followup after implementing 
Dusty Leary's  very complete suggestion.


My program is now running 547 playouts/sec and thread, but a lot of 
optimizations were removed so I'm sure there's space for growth here. It 
is now spending 75% of the time in the selection of the play itself by 
probability distribution. The patterns were simplified to not needing 
actual liberty/capture counts.


I'm also considering the whole board for pattern matching only about 1/4 
of the time, like Petr suggested; simplified ko detection, hardcoded 
some patterns, cached all matchable pattern configurations at startup 
(that's 351882 from just 13 base patterns from GNU Go's 
montegnu_classic), etc.


As for more complete heuristics, my UCT search does have itself some 
very heavy heuristics and needs real liberty counts, but I need faster 
playouts before feeling the impact of the UCT states initialization.


Big thanks to Dusty for the structure explanation. I had already thought 
of something similar but never tested it because group captures seemed 
too heavy. I was wrong since the real cost is in testing atari/counting 
liberties.


Thanks again,
Gonçalo

On 15/10/2015 10:30, Petr Baudis wrote:

On Wed, Oct 14, 2015 at 06:00:56PM -0700, Dusty Leary wrote:

The trick to avoid recursively counting liberties:
Track the liberties for a group/chain using a simplified data structure
that looks like struct ChainLibertyInfo { int liberty_count; int
liberty_sum; int liberty_sum_squares; }

The interesting thing about this data structure is that it's a Set which
can answer the isInAtari() query and the getAtariPoint() query, without
having to track a lot of data.  But it doesn't support enumerating all the
liberties.

   This is a nice trick I once implemented too.  But for any kind of
interesting tactical evaluation (which is an important ingredient for
a strong program), you end up needing to be able to enumerate at least
two liberties, ideally even three.  Then, you can't use this trick.


   In Pachi, I got inspired by GNUGo and track liberties only up to
N liberties (N=5 I think).  Any group with more than N is regarded
as having N libs.  This cuts off a lot of overhead, IIRC it helped
me a lot.

   If you are doing probability distribution stuff, I think a popular
trick is first deciding whether you are going to look just in last move
neighborhood or tenuki; most of the time, your roll will go with the
last move neighborhood and you won't need to spend a lot of time going
through the whole board.

   In general, you may simply want to look at how other programs do
things...  There's plenty of fast open source stuff out there.



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

Re: [Computer-go] Playout speed... again

[David Fotland]

Yes, that is correct.  Actually more than a factor of ten since the machine in 
2008 was slower.  I wrote the MFGO Monte carlo engine between January 2008 and 
the world championship in September 2008.  The fast playout timing was probably 
sometime in April, when it was still weaker than gnugo.

 

I implemented light playouts first, and highly optimized the code for speed.  
The light playouts kept track of liberty count, but not liberty location.  Then 
I added 3x3 patterns, lists of liberty points, move generation heuristics, and 
eventually included the entire old Many Faces of Engine move generator as a 
prior.

 

Here is a plot of MFGO win rate vs gnugo for each version of the program I 
tested in 2008 between January and August.  This was 9x9 board with 5000 
playouts.  I had a big test cluster so I could run several test versions a day, 
typically 1000 games per test run.  I’m only on version 1250 now.  My effort 
slowed way down after 2009.

 

 

 



 

> -Original Message-

> From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf

> Of Lucas, Simon M

> Sent: Thursday, October 15, 2015 12:51 AM

> To: computer-go@computer-go.org

> Subject: Re: [Computer-go] Playout speed... again

> 

> Did I read that correctly?  The number of playouts per second for Many

> Faces has gone DOWN by a factor of 10?  (25,000 -> 2,500) Presumably do to

> the playouts being heavier.

> 

> Simon

> 

> 

> -Original Message-

> From: Computer-go [ <mailto:computer-go-boun...@computer-go.org> 
> mailto:computer-go-boun...@computer-go.org] On Behalf

> Of David Fotland

> Sent: 15 October 2015 06:51

> To:  <mailto:computer-go@computer-go.org> computer-go@computer-go.org

> Subject: Re: [Computer-go] Playout speed... again

> 

> In 2008 Many Faces was getting about 25k light playouts per second on

> 19x19.  Today it gets 2500 playouts per second on one thread of an i7-

> 3770.  I don t use a probability distribution in the UCT tree.  I both

> count liberties and maintain lists of liberty points, but all

> incrementally.  In the playouts I use 3x3 patterns with gammas like

> Crazystone, not just the Mogo patterns, but I only do a partial

> distribution.  I also do local ladder searches and many other local

> tactics things.

> 

> David

> 

> > -Original Message-

> > From: Computer-go [ <mailto:computer-go-boun...@computer-go.org> 
> > mailto:computer-go-boun...@computer-go.org] On

> > Behalf Of Gon alo Mendes Ferreira

> > Sent: Wednesday, October 14, 2015 3:27 PM

> > To: [mailing list] Computer Go

> > Subject: [Computer-go] Playout speed... again

> >

> > Hi, I've been searching the mailing list archive but can't find an

> > answer to this.

> >

> > What is currently the number of playouts per thread per second that

> > the best programs can do, without using the GPU?

> >

> > I'm getting 2075 in light playouts and just 55 in heavy playouts. My

> > heavy playouts use MoGo like patterns and are probability distributed,

> > with liberty/capture counts/etc only updated when needed, so it should

> > be pretty efficient.

> >

> > What would be a good ballpark for this?

> >

> > Thank you,

> > Gon alo F.

> > ___

> > Computer-go mailing list

> >  <mailto:Computer-go@computer-go.org> Computer-go@computer-go.org

> >  <http://computer-go.org/mailman/listinfo/computer-go> 
> > http://computer-go.org/mailman/listinfo/computer-go

> 

> ___

> Computer-go mailing list

>  <mailto:Computer-go@computer-go.org> Computer-go@computer-go.org

>  <http://computer-go.org/mailman/listinfo/computer-go> 
> http://computer-go.org/mailman/listinfo/computer-go

> ___

> Computer-go mailing list

>  <mailto:Computer-go@computer-go.org> Computer-go@computer-go.org

>  <http://computer-go.org/mailman/listinfo/computer-go> 
> http://computer-go.org/mailman/listinfo/computer-go

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

[Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

Hi, I've been searching the mailing list archive but can't find an 
answer to this.


What is currently the number of playouts per thread per second that the 
best programs can do, without using the GPU?


I'm getting 2075 in light playouts and just 55 in heavy playouts. My 
heavy playouts use MoGo like patterns and are probability distributed, 
with liberty/capture counts/etc only updated when needed, so it should 
be pretty efficient.


What would be a good ballpark for this?

Thank you,
Gonçalo F.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Erik van der Werf]

You should be able to do at least 50 times faster.

Erik

On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira  wrote:
> Hi, I've been searching the mailing list archive but can't find an answer to
> this.
>
> What is currently the number of playouts per thread per second that the best
> programs can do, without using the GPU?
>
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My heavy
> playouts use MoGo like patterns and are probability distributed, with
> liberty/capture counts/etc only updated when needed, so it should be pretty
> efficient.
>
> What would be a good ballpark for this?
>
> Thank you,
> Gonçalo F.
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Erik van der Werf]

I don't know, what language are you using? Did you do any
optimizations? How many clock cycles does it take your program on
average to make and undo a move (just counting the core board update)?

BTW you didn't specify board size and hardware, so I assumed 19x19 and
a modern PC.

Erik

On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira  wrote:
> Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive
> pruning, mercy thresholds and max playout depth, etc. What could I be
> missing that is that much of a boost in the playouts, in your experience?
>
> Gonçalo
>
>
> On 14/10/2015 23:40, Erik van der Werf wrote:
>>
>> You should be able to do at least 50 times faster.
>>
>> Erik
>>
>> On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira 
>> wrote:
>>>
>>> Hi, I've been searching the mailing list archive but can't find an answer
>>> to
>>> this.
>>>
>>> What is currently the number of playouts per thread per second that the
>>> best
>>> programs can do, without using the GPU?
>>>
>>> I'm getting 2075 in light playouts and just 55 in heavy playouts. My
>>> heavy
>>> playouts use MoGo like patterns and are probability distributed, with
>>> liberty/capture counts/etc only updated when needed, so it should be
>>> pretty
>>> efficient.
>>>
>>> What would be a good ballpark for this?
>>>
>>> Thank you,
>>> Gonçalo F.
>>> ___
>>> Computer-go mailing list
>>> Computer-go@computer-go.org
>>> http://computer-go.org/mailman/listinfo/computer-go
>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Gonçalo Mendes Ferreira]

This reply is to both Erik and Petr,

I was running a profile on the program just now. It spends about 90% 
updating information to speed up the playout, these are captures and 
liberties after play and the resulting 3x3 codified part of the board. 
These are updated when needed, so about 4-8 intersections per play on 
average.


In the updating information part, the most costly is a recursive 
function that counts liberties (it spends itself 33% of all time).


It is in C in a modern PC, board size is 19x19. The heavy playout count 
in the meanwhile was raised to 66 per sec/thread. I'm doing a lot of 
optimizing and in the playouts part there is not much I can thin out 
more. With these profiling results I'll attack the liberty counting 
primitives next. You probably know some method more efficient than a 
recursive search over the board surface.


Gonçalo

On 15/10/2015 00:43, Erik van der Werf wrote:

I don't know, what language are you using? Did you do any
optimizations? How many clock cycles does it take your program on
average to make and undo a move (just counting the core board update)?

BTW you didn't specify board size and hardware, so I assumed 19x19 and
a modern PC.

Erik

On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira  wrote:

Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive
pruning, mercy thresholds and max playout depth, etc. What could I be
missing that is that much of a boost in the playouts, in your experience?

Gonçalo


On 14/10/2015 23:40, Erik van der Werf wrote:

You should be able to do at least 50 times faster.

Erik

On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira 
wrote:

Hi, I've been searching the mailing list archive but can't find an answer
to
this.

What is currently the number of playouts per thread per second that the
best
programs can do, without using the GPU?

I'm getting 2075 in light playouts and just 55 in heavy playouts. My
heavy
playouts use MoGo like patterns and are probability distributed, with
liberty/capture counts/etc only updated when needed, so it should be
pretty
efficient.

What would be a good ballpark for this?

Thank you,
Gonçalo F.


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

Re: [Computer-go] Playout speed... again

[Dusty Leary]

You are noting that you spend most of your time in counting liberties.  I
am not an expert at computer Go, but I know a little bit about this so I
can write an answer for you.

There is a paper out there written by someone who is probably on this list
that talks about a few efficient datastructures for computer Go.  My
apologies but I can neither remember the paper where I read this, nor the
author.

The trick to avoid recursively counting liberties:
Track the liberties for a group/chain using a simplified data structure
that looks like struct ChainLibertyInfo { int liberty_count; int
liberty_sum; int liberty_sum_squares; }

The interesting thing about this data structure is that it's a Set which
can answer the isInAtari() query and the getAtariPoint() query, without
having to track a lot of data.  But it doesn't support enumerating all the
liberties.

This data structure supports adding and removing liberties, and crucially,
it supports adding the same liberty multiple times, and only counting it
once for atari purposes.  So, when you add a stone to a chain, you just
examine the 4 neighbors of the stone, and for each one, if it's empty, add
it to the liberties for that chain.  Double or triple-counting the same
point will still work.

Address each point on the board as an integer.  When you add a liberty,
that looks like:  void add(int pt) { ++liberty_count; liberty_sum += pt;
liberty_sum_squares += pt*pt; }

Removing liberties and merging chains is pretty straightforward.

If you add point 3 to the chain four times, then you have {
liberty_count=4; liberty_sum=12; liberty_sum_squares=36; }

If you then remove point 3 four times, you get back to empty {
liberty_count=0; liberty_sum=0; liberty_sum_squares=0; }

isInAtari() looks like:  (liberty_count > 0) && (liberty_count *
liberty_sum_squares) == (liberty_sum * liberty_sum)

(Note that this answers 'true' for the above case of adding point 3 to the
chain 4 times...  This chain is in atari because it only has one liberty,
even though it was multiply-added)

If the chain is in atari, then the atari point is (liberty_sum /
liberty_count);

This allows you to track information for life/death of groups with very
little overhead.  But if your heavy playouts need to know actual liberty
count for capture race etc, then you'll still need something else.


-D

On Wed, Oct 14, 2015 at 5:09 PM, Gonçalo Mendes Ferreira 
wrote:

> This reply is to both Erik and Petr,
>
> I was running a profile on the program just now. It spends about 90%
> updating information to speed up the playout, these are captures and
> liberties after play and the resulting 3x3 codified part of the board.
> These are updated when needed, so about 4-8 intersections per play on
> average.
>
> In the updating information part, the most costly is a recursive function
> that counts liberties (it spends itself 33% of all time).
>
> It is in C in a modern PC, board size is 19x19. The heavy playout count in
> the meanwhile was raised to 66 per sec/thread. I'm doing a lot of
> optimizing and in the playouts part there is not much I can thin out more.
> With these profiling results I'll attack the liberty counting primitives
> next. You probably know some method more efficient than a recursive search
> over the board surface.
>
> Gonçalo
>
>
> On 15/10/2015 00:43, Erik van der Werf wrote:
>
>> I don't know, what language are you using? Did you do any
>> optimizations? How many clock cycles does it take your program on
>> average to make and undo a move (just counting the core board update)?
>>
>> BTW you didn't specify board size and hardware, so I assumed 19x19 and
>> a modern PC.
>>
>> Erik
>>
>> On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira 
>> wrote:
>>
>>> Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive
>>> pruning, mercy thresholds and max playout depth, etc. What could I be
>>> missing that is that much of a boost in the playouts, in your experience?
>>>
>>> Gonçalo
>>>
>>>
>>> On 14/10/2015 23:40, Erik van der Werf wrote:
>>>
 You should be able to do at least 50 times faster.

 Erik

 On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira <
 go...@sapo.pt>
 wrote:

> Hi, I've been searching the mailing list archive but can't find an
> answer
> to
> this.
>
> What is currently the number of playouts per thread per second that the
> best
> programs can do, without using the GPU?
>
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My
> heavy
> playouts use MoGo like patterns and are probability distributed, with
> liberty/capture counts/etc only updated when needed, so it should be
> pretty
> efficient.
>
> What would be a good ballpark for this?
>
> Thank you,
> Gonçalo F.
>

> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> 

Re: [Computer-go] Playout speed... again

[Hideki Kato]

Hi,

You looks not using incremental-updating approach.  This makes 
everything faster.

Hideki

Goncalo Mendes Ferreira: <561eee9d.4030...@sapo.pt>:
>This reply is to both Erik and Petr,

>

>I was running a profile on the program just now. It spends about 90% 

>updating information to speed up the playout, these are captures and 

>liberties after play and the resulting 3x3 codified part of the board. 

>These are updated when needed, so about 4-8 intersections per play on 

>average.

>

>In the updating information part, the most costly is a recursive 

>function that counts liberties (it spends itself 33% of all time).

>

>It is in C in a modern PC, board size is 19x19. The heavy playout count 

>in the meanwhile was raised to 66 per sec/thread. I'm doing a lot of 

>optimizing and in the playouts part there is not much I can thin out 

>more. With these profiling results I'll attack the liberty counting 

>primitives next. You probably know some method more efficient than a 

>recursive search over the board surface.

>

>Gonçalo

>

>On 15/10/2015 00:43, Erik van der Werf wrote:

>> I don't know, what language are you using? Did you do any

>> optimizations? How many clock cycles does it take your program on

>> average to make and undo a move (just counting the core board update)?

>>

>> BTW you didn't specify board size and hardware, so I assumed 19x19 and

>> a modern PC.

>>

>> Erik

>>

>> On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira  
>> wrote:

>>> Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive

>>> pruning, mercy thresholds and max playout depth, etc. What could I be

>>> missing that is that much of a boost in the playouts, in your experience?

>>>

>>> Gonçalo

>>>

>>>

>>> On 14/10/2015 23:40, Erik van der Werf wrote:

 You should be able to do at least 50 times faster.



 Erik



 On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira 

 wrote:

> Hi, I've been searching the mailing list archive but can't find an answer

> to

> this.

>

> What is currently the number of playouts per thread per second that the

> best

> programs can do, without using the GPU?

>

> I'm getting 2075 in light playouts and just 55 in heavy playouts. My

> heavy

> playouts use MoGo like patterns and are probability distributed, with

> liberty/capture counts/etc only updated when needed, so it should be

> pretty

> efficient.

>

> What would be a good ballpark for this?

>

> Thank you,

> Gonçalo F.

>

>___

>Computer-go mailing list

>Computer-go@computer-go.org

>http://computer-go.org/mailman/listinfo/computer-go
-- 
Hideki Kato 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[Petr Baudis]

  Hi!

On Wed, Oct 14, 2015 at 11:27:27PM +0100, Gonçalo Mendes Ferreira wrote:
> Hi, I've been searching the mailing list archive but can't find an answer to
> this.
> 
> What is currently the number of playouts per thread per second that the best
> programs can do, without using the GPU?
> 
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My heavy
> playouts use MoGo like patterns and are probability distributed, with
> liberty/capture counts/etc only updated when needed, so it should be pretty
> efficient.
> 
> What would be a good ballpark for this?

  What board size are we talking about?

  ...Pachi does roughly 2000 heavy playouts per second per thread on
19x19.  It doesn't do it probability distribution style, which is though
just about 0.25 to 0.5 slowdown iirc.  Profile your program to find
hotspots.

  Maybe you are doing it in Python?  Michi's heavy playouts (also not
probability distribution) are about 15 per second per thread on 13x13.

-- 
Petr Baudis
If you have good ideas, good data and fast computers,
you can do almost anything. -- Geoffrey Hinton
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Playout speed... again

[David Fotland]

In 2008 Many Faces was getting about 25k light playouts per second on 19x19.  
Today it gets 2500 playouts per second on one thread of an i7-3770.  I don’t 
use a probability distribution in the UCT tree.  I both count liberties and 
maintain lists of liberty points, but all incrementally.  In the playouts I use 
3x3 patterns with gammas like Crazystone, not just the Mogo patterns, but I 
only do a partial distribution.  I also do local ladder searches and many other 
local tactics things.

David

> -Original Message-
> From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf
> Of Gonçalo Mendes Ferreira
> Sent: Wednesday, October 14, 2015 3:27 PM
> To: [mailing list] Computer Go
> Subject: [Computer-go] Playout speed... again
> 
> Hi, I've been searching the mailing list archive but can't find an answer
> to this.
> 
> What is currently the number of playouts per thread per second that the
> best programs can do, without using the GPU?
> 
> I'm getting 2075 in light playouts and just 55 in heavy playouts. My heavy
> playouts use MoGo like patterns and are probability distributed, with
> liberty/capture counts/etc only updated when needed, so it should be
> pretty efficient.
> 
> What would be a good ballpark for this?
> 
> Thank you,
> Gon alo F.
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go

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