Okay, so I created a FastSloppyBoard class that works like a Board
but doesn't maintain ko or Zobrist information. Not all the wires are
plugged in yet (e.g., I'm not incorporating the results into the
tree), but this got me about a 20% improvement in run per second. For
those of you keepin
I see. I only recently had this realization that the within-tree and
purely-random parts of the search were deeply different. I'll take a
shot at this.
Thanks,
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 7, 2006, at 3:21
Peter,
I also want to point out that I DO do full KO testing, but it's just in
the tree search - it's the Monte/Carlo part that's a waste of time.
I say that because monte/carlo is a RANDOM search, it's not going to
deal with any positional finesses and such. It's too expensive even to
mainta
On Thu, 2006-12-07 at 14:09 -0800, Peter Drake wrote:
> > In the search tree part of the game, (not the random simulation
> > part) I
> > make state copies, do Zobrist hashing and full repetition checks and
> > other stuff - the tree part is cheap.
>
> Agreed -- the playing of moves is the expe
On 7, Dec 2006, at 2:09 PM, Peter Drake wrote:
Are you one of those who advocates ignoring the ko rule during MC
searches?
SlugGo is not monte carlo, but we launch parallel lookahead
sequences, so its not really different than your threads. We ignore
the ko info in the lookaheads and only
On Dec 7, 2006, at 11:08 AM, Don Dailey wrote:
On Thu, 2006-12-07 at 09:17 -0800, Peter Drake wrote:
I do have the undo ability, but I think it's done in (I think) a
very
efficient way. For example, when I want to undo a bunch of move at
once (e.g., after a MC run) I just reduce a stack pointer
g.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Thursday, December 07, 2006 9:37 AM
To: computer-go
Subject: Re: Threads (was Re: [computer-go] experiments with D programming)
Those of you with multithreaded UCT programs -- how d
On Thu, 2006-12-07 at 09:17 -0800, Peter Drake wrote:
> I do have the undo ability, but I think it's done in (I think) a
> very
> efficient way. For example, when I want to undo a bunch of move at
> once (e.g., after a MC run) I just reduce a stack pointer.
BINGO! I'm pretty sure that is yo
Precisely: I'm getting almost optimal use of my dual-core processor.
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 7, 2006, at 10:47 AM, Don Dailey wrote:
On Thu, 2006-12-07 at 10:24 -0800, Peter Drake wrote:
Got it -- now I'
On Thu, 2006-12-07 at 10:24 -0800, Peter Drake wrote:
> Got it -- now I'm getting just under 10,000 games per second! Whee!
Hold on, I thought the non-threaded version was doing 5,000? What
exactly did you change? Or are you just using 2 processors more
efficiently to get 10,000 games?
- Don
Got it -- now I'm getting just under 10,000 games per second! Whee!
(FWIW, I actually don't have the UCT part in there yet -- these are
purely random games.)
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 7, 2006, at 10:07 A
There is a pattern that i don't remember the name for
this kind of tasks.
You should create a pool of n threads and assign work
to them from a main thread. You can use two queue per
thread.
On "in" queue you will insert a task, and on "out"
queue you will read the task's result.
Threads are bloc
Aha! Now I get it. You only have to look at the tree during the
opening part of the run. Once you've fallen off and are making purely
random moves, you can let someone else use the tree.
Thanks!
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~
> The problem is that a single MC run takes about 1/5 of a millisecond,
> so it's not worth the overhead of putting it off into another thread.
Creating a thread for each MC simulation is clearly very costy.
> I need some way to tell a thread to do many runs, then somehow
> incorporate the multipl
On Dec 7, 2006, at 9:42 AM, [EMAIL PROTECTED] wrote:
Hello,
Those of you with multithreaded UCT programs -- how do you do it?
Doesn't UCT pretty much require updating a common data structure
after each MC run?
in MoGo we simply protect the tree access using a mutex, so only
the MC
simulations
I'm afraid I don't follow you. I THINK I'm doing what you describe.
My Player object creates several threads, each of which plays a game.
After all of the games are completed, the main thread incorporates
them into the search tree. Here's the Java:
timer.schedule(interrupt, MSEC_PER_MOVE);
Hello,
> Those of you with multithreaded UCT programs -- how do you do it?
> Doesn't UCT pretty much require updating a common data structure
> after each MC run?
in MoGo we simply protect the tree access using a mutex, so only the MC
simulations are run in parallel. The tree update is done by onl
> Those of you with multithreaded UCT programs -- how
> do you do it?
> Doesn't UCT pretty much require updating a common
> data structure
> after each MC run?
you could hand a job (starting position) to each
thread and have the thread manager update a shared
memory segment that they all can r
Those of you with multithreaded UCT programs -- how do you do it?
Doesn't UCT pretty much require updating a common data structure
after each MC run?
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 7, 2006, at 9:17 AM, Peter Dr
On Dec 7, 2006, at 9:05 AM, Don Dailey wrote:
Are you trying to keep a lot of information updated? Mine only tries
to play random games as fast as possible. It does not have the
ability
to undo moves - this is easily handled by copying state when you need
this feature.
I do have the und
20 matches
Mail list logo
