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

. "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

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

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

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

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

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

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

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

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

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

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