David Fotland wrote:
> Are you not using rave? If you keep rave counters for each legal move in
> the node it should be much bigger than this.
If you don't start keeping RAVE stats until the node is expanded, it need only
cost two more integers per node (or perhaps a bit more if there is some
con
-go.org] On Behalf Of Michael Williams
Sent: Thursday, May 14, 2009 7:08 AM
To: computer-go@computer-go.org
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
C# does. It should only take 30 bytes per node to store the information I
need to have. But somehow that turns into
nt: Thursday, May 14, 2009 7:08 AM
> To: computer-go@computer-go.org
> Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
>
> C# does. It should only take 30 bytes per node to store the information I
> need to have. But somehow that turns into 50 bytes.
It's on my list of things to improve.
Michael Williams wrote:
C# does. It should only take 30 bytes per node to store the information
I need to have. But somehow that turns into 50 bytes. Byte alignment
plus class overhead, I guess.
Matthew Woodcraft wrote:
Michael Williams wrote:
I wan
C# does. It should only take 30 bytes per node to store the information I need to have. But somehow that turns into 50 bytes. Byte alignment plus class
overhead, I guess.
Matthew Woodcraft wrote:
Michael Williams wrote:
I want to correct that last statement. With about 350M nodes currentl
Michael Williams wrote:
> I want to correct that last statement. With about 350M nodes currently
> in the tree (~30M of which fit into memory), I am averaging 0.06 disk
> reads per tree traversal.
What makes the nodes so big?
-M-
___
computer-go mailin
I want to correct that last statement. With about 350M nodes currently in the tree (~30M of which fit into memory), I am averaging 0.06 disk reads per tree
traversal. Must less than "several". In hindsight, "several" wasn't a good guess. The 0.06 number will get a little worse as the tree gets
1897
*From:* Michael Williams
*To:* computer-go
*Sent:* Tuesday, May 12, 2009 1:09:41 PM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
That's basically what I'm doing. Except that there is no depth limit
and only the parts of the tree that you
nly regarded as entirely proper and normal.
>
>
> – John Beverley Robinson, 1897
>
> --
> *From:* Michael Williams
> *To:* computer-go
> *Sent:* Tuesday, May 12, 2009 10:18:28 AM
> *Subject:* Re: [computer-go] Implications of a CPU vs Memory t
is
> commonly regarded as entirely proper and normal.
>
>
> – John Beverley Robinson, 1897
>
>
>
> *From:* Michael Williams
> *To:* computer-go
> *Sent:* Tuesday, May 12, 2009 10:18:28 AM
erley Robinson, 1897
*From:* Michael Williams
*To:* computer-go
*Sent:* Tuesday, May 12, 2009 10:18:28 AM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
In my system, I can retrieve the children of a
Just a reminder that epsilon trick (invented by Jakub Pawlewicz) can
be used to avoid excessive memory usage (reuse memory) without
significant performance loss. It has been tested for proof number
search, but there is no reason for it to behave differently in MCTS.
Lukasz Lew
On Tue, May 12, 200
Those numbers are the average after the tree has grown to 1B nodes. I'm sure the cache hates me. Each tree traversal will likely make several reads from
random locations in a 50 GB file.
Don Dailey wrote:
So you are saying that use disk memory for this?
This could be pretty deceiving if m
So you are saying that use disk memory for this?
This could be pretty deceiving if most of your reads and writes are
cached.What happens when your tree gets much bigger than available
memory?
- Don
On Tue, May 12, 2009 at 1:18 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:
> I
, 1897
From: Michael Williams
To: computer-go
Sent: Tuesday, May 12, 2009 10:18:28 AM
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
In my system, I can retrieve the children of any node at a rate of about 100k
nodes/sec.
And I can save
In my system, I can retrieve the children of any node at a rate of about 100k
nodes/sec.
And I can save nodes at a rate of over 1M nodes/sec (this is much faster
because in my implementation, the operation is sequential on disk).
Those numbers are from 6x6 testing.
Don Dailey wrote:
This is
This is probably a good solution. I don't believe the memory has to be
very fast at all because even with light playouts you are doing a LOT of
computation between memory accesses.
All of this must be tested of course. In fact I was considering if disk
memory could not be utilized as a kind
at is commonly regarded
as entirely proper and normal.
– John Beverley Robinson, 1897
From: Michael Williams
To: computer-go
Sent: Tuesday, May 12, 2009 9:48:19 AM
Subject: Re: [computer-go] Implications of a CPU vs Memory trend on MCTS
It depends on how yo
cool, that's what i was wondering -- that you'd have to treat it
as something inbetween ram and a HD.
thanks,
s.
On Tue, May 12, 2009 at 12:48 PM, Michael Williams
wrote:
> It depends on how you use it and how much you pay for it. If you get a
> high-end Intel SSD, you can treat it however you
It depends on how you use it and how much you pay for it. If you get a high-end Intel SSD, you can treat it however you like. But I can't afford that. I got
a cheap SSD and so I had shape my algorithm around which kind of disk operations it likes and which ones it doesn't.
steve uurtamo wrot
is the ssd fast enough to be practical?
s.
On Tue, May 12, 2009 at 12:41 PM, Michael Williams
wrote:
> Don Dailey wrote:
>>
>> On Tue, May 12, 2009 at 12:16 PM, Michael Williams
>> mailto:michaelwilliam...@gmail.com>> wrote:
>>
>> I have a trick ;)
>>
>> I am currently creating MCTS trees
Don Dailey wrote:
On Tue, May 12, 2009 at 12:16 PM, Michael Williams
mailto:michaelwilliam...@gmail.com>> wrote:
I have a trick ;)
I am currently creating MCTS trees of over a billion nodes on my 4GB
machine.
Ok, I'll bite.What is your solution?
I use an SSD. There are m
On Tue, May 12, 2009 at 12:16:46PM -0400, Michael Williams wrote:
> I have a trick ;)
>
> I am currently creating MCTS trees of over a billion nodes on my 4GB
> machine.
That is the easy part. Can you also (decompress and) read it after you have
created it?
- Heikki
(ha-ha, only serious)
All,
let me chip in with some additional thoughts about massively parallel
hardware.
I recently implemented Monte Carlo playouts on CUDA, to run them on the
GPU. It was more or less a "naive" implementation (read: a more or less
straight port with optimised memory access patterns). I am hope
On Tue, May 12, 2009 at 12:16 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:
> I have a trick ;)
>
> I am currently creating MCTS trees of over a billion nodes on my 4GB
> machine.
Ok, I'll bite.What is your solution?
- Don
>
>
> ___
Compression tricks will only take you so far. Assuming you can get 2 to 1,
for instance, that doesn't scale. It will put the problem off for 1
generation for instance.It's not something you can keep doing - it's a 1
time thing but the memory vs CPU power thing may be constant.
So while it
I have a trick ;)
I am currently creating MCTS trees of over a billion nodes on my 4GB machine.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
This is a great post, and some good observations. I agree with your
conclusions that CPU power is increasing faster than memory and memory
bandwidth. Let me give you my take on this.
In a nutshell, I believe memory will increasingly become the limiting
factor no matter what direction we go.
increasing memory is more expensive than increasing cpu speed
at this point. there was an addressing issue with 32bit machines,
but that shouldn't be too much of an issue anymore. most people
want to pay less than or equal to the price of their last machine
whenever they buy one, though, so compa
Summary: The trend in computer systems has been for CPU power to grow much
faster than memory size. The implication of this trend for MCTS computer go
implementations is that "heavy" playouts will have a significant cost
advantage
in the future.
I bought a Pentium D 3GHz system a few years back.
30 matches
Mail list logo
