Re: [Computer-go] Computer-go Digest, Vol 69, Issue 2

[djhbrown .]

.
"sharing code is typically not going to be practical."

that's not what i suggested.  perhaps someone else can explain the concept
of message-passing distributed architecture better than me
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Computer-go Digest, Vol 69, Issue 2

[Jim O'Flaherty]

You mean literally the slowest of all the constraints in all of software
engineering (excluding waiting on UI input) in a domain that cannot
currently get enough unconstrained CPU and memory cycles?

On Fri, Oct 2, 2015 at 8:53 AM, djhbrown .  wrote:

> .
> "sharing code is typically not going to be practical."
>
> that's not what i suggested.  perhaps someone else can explain the concept
> of message-passing distributed architecture better than me
>
>
>
> ___
> 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] Computer-go Digest, Vol 69, Issue 2

[David Doshay]

SlugGo used message passing in a distributed architecture and started as a 
shell over the top of multiple instantiations of GNU Go in order to evaluate a 
look-ahead tree that GNU Go did not build. It was one of the strongest programs 
before the MCTS programs hit their stride. Now it would not be competitive: 
It’s peak performance was to beat a human 8k at the Cotsen Open when other 
programs were playing near 12k.

Much like you are suggesting with HALy, SlugGo was an attempt to integrate 
different ways to compute the moves, including an expert system based upon the 
concepts used by my Go teacher (Lance Kemper, 5D), but we did not get the 
arbitration of moves suggested by different ‘brains’ to be successfully 
evaluated (although somebody else might be able to). At some point we found 
that we had a stronger engine just doing MCTS instead of all the other 
computation.

I think that your premise that there is not much sharing in computer Go is 
wrong. The exchange of ideas and data on this forum far exceeds what takes 
place in many other computer games. The rapid spread of the MCTS technique, the 
way that RAVE, AMAF, and other methods were developed in a very open way, and 
the recent integration of the DCNN data into other engines displays to me that 
Go programmers have found a healthy balance between competition and cooperation 
… or maybe I should say exploration / exploitation.


Cheers,
David G Doshay

ddos...@mac.com





> On 2, Oct 2015, at 6:53 AM, djhbrown .  wrote:
> 
> .
> "sharing code is typically not going to be practical."
> 
> that's not what i suggested.  perhaps someone else can explain the concept of 
> message-passing distributed architecture better than me
> 
> 
> ___
> 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] Computer-go Digest, Vol 69, Issue 2

[Petri Pitkanen]

I think very few people here do not know message passing style of
programming.  I just not suited problem at hand. Not very cPU efficient.
This is high speed simulation anyways



2015-10-02 16:53 GMT+03:00 djhbrown . :

> .
> "sharing code is typically not going to be practical."
>
> that's not what i suggested.  perhaps someone else can explain the concept
> of message-passing distributed architecture better than me
>
>
>
> ___
> 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] Computer-go Digest, Vol 69, Issue 2

[Gonçalo Mendes Ferreira]

I actually agree some form of more de facto cooperation could exist. 
Message passing is already used in clusters anyways, some hierarchical 
architecture for Go with different providers could be implemented. There 
are two immediate problems however:


1. Brown said there are some programs that are much better at some tasks 
than others, but I'm not so sure about this and how much stronger would 
be a joint effort to compensate the increase in complexity/comm. 
overhead/etc.
2. To have a joint effort there would have to be a strong financial 
force to pull everyone into the same time table, licensing model, and so 
on. Currently research on computer Go seems to be supported by either 
commercial endeavors or academic research. Even if this did produce a 
stronger player, without a financial force most people would prefer to 
do things their own way, instead of adhering to the Go juggernaut. It 
would become an effort of just a few "computer Go experts".


The more I think about it the more the word "MoGo" comes to mind.

Gonçalo F.

On 02/10/2015 19:26, Petri Pitkanen wrote:

I think very few people here do not know message passing style of
programming.  I just not suited problem at hand. Not very cPU efficient.
This is high speed simulation anyways



2015-10-02 16:53 GMT+03:00 djhbrown . :


.
"sharing code is typically not going to be practical."

that's not what i suggested.  perhaps someone else can explain the concept
of message-passing distributed architecture better than me


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

Re: [Computer-go] Computer-go Digest, Vol 69, Issue 2

[David Doshay]

The messages need not be used on a single CPU; in SlugGo MPI was our way to 
start jobs on remote nodes. The time to wrap and unwrap the messages was not 
significant compared to the time used to calculate a suggested move.

Cheers,
David G Doshay

ddos...@mac.com





> On 2, Oct 2015, at 11:26 AM, Petri Pitkanen  
> wrote:
> 
> I think very few people here do not know message passing style of 
> programming.  I just not suited problem at hand. Not very cPU efficient. This 
> is high speed simulation anyways
> 
> 
> 
> 2015-10-02 16:53 GMT+03:00 djhbrown .  >:
> .
> "sharing code is typically not going to be practical."
> 
> that's not what i suggested.  perhaps someone else can explain the concept of 
> message-passing distributed architecture better than me
> 
> 
> 
> ___
> 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