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 mailing
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
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
, 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. Byte alignment plus
class
overhead, I guess
-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
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
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.
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
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.
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/
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
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
___
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
Don Dailey wrote:
On Tue, May 12, 2009 at 12:16 PM, Michael Williams
michaelwilliam...@gmail.com 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?
is the ssd fast enough to be practical?
s.
On Tue, May 12, 2009 at 12:41 PM, Michael Williams
michaelwilliam...@gmail.com wrote:
Don Dailey wrote:
On Tue, May 12, 2009 at 12:16 PM, Michael Williams
michaelwilliam...@gmail.com mailto:michaelwilliam...@gmail.com wrote:
I have a trick ;)
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
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
michaelwilliam...@gmail.com wrote:
It depends on how you use it and how much you pay for it. If you get a
high-end Intel SSD,
-go] Implications of a CPU vs Memory trend on MCTS
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
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
.
– John Beverley Robinson, 1897
From: Michael Williams michaelwilliam...@gmail.com
To: computer-go computer-go@computer-go.org
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
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:
In
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
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,
Beverley Robinson, 1897
*From:* Michael Williams michaelwilliam...@gmail.com
*To:* computer-go computer-go@computer-go.org
*Sent:* Tuesday, May 12, 2009 10:18:28 AM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend
: 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 need get loaded back into memory. It's not a
playing engine yet so it can't build
proper and normal.
– John Beverley Robinson, 1897
--
*From:* Michael Williams michaelwilliam...@gmail.com
*To:* computer-go computer-go@computer-go.org
*Sent:* Tuesday, May 12, 2009 10:18:28 AM
*Subject:* Re: [computer-go] Implications of a CPU vs Memory trend
*From:* Michael Williams michaelwilliam...@gmail.com
*To:* computer-go computer-go@computer-go.org
*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
27 matches
Mail list logo
