Standard approach to the cpu is getting to the limit. New technologies could
emerge. The future is hard to predict. One approach has not yet being published
in Go, that is the special purpose cpu. One probably should start getting
familiar with terms of digtal design, such as barrel shifter and
From: Don Dailey dailey@gmail.com
My basic observation is that over the several year period I have been in this
forum, I have detected a huge amount of resistance to the idea that hardware
could have anything to do with computer go strength, despite
Terry,
I don't think the part of the argument looking at hardware is sound. You
are assuming that computing power is going to continue to provide a
linear strength increase with every doubling. I think the argument being
made by a few of the previous posters is that the strength curve is
] On Behalf Of Don Dailey
Sent: Wednesday, June 10, 2009 9:27 PM
To: computer-go
Subject: Re: [computer-go] MCTS, 19x19, hitting a wall?
My basic observation is that over the several year period I have been in
this forum, I have detected a huge amount of resistance to the idea that
hardware
In my humble opinion, we need a change in the algorithm. The numbers are
misleading - 95% of win of
MoGo on 32 nodes against MoGo on 1 node (this is a real number for 19x19)
certainly means that the
parallel version is stronger than the sequential version, but not much
better, far less than what
On Wednesday 10 June 2009 22:15:22 Ian Osgood wrote:
We have evidence against going this low: Rybka and several other
modern engines were ported to the dedicated computers Resurrection
(203 MHz StrongArm) and Revelation (500 MHz XScale). Rybka's rating
in the SSDF pool on these platforms
On Wednesday 10 June 2009 18:48:55 Martin Mueller wrote:
Currently, we try to sidestep this fundamental problem by replacing
local search with local knowledge, such as patterns. But that does not
fully use the power of search.
So, has anyone tried recursive UCT (using UCT again in the
Would this be a simple way of using many cores effectively?
Otherwise I cannot see how recursive UCT would be anything else than
an ineffective implementation of UCT. Unless it provides some
information that could be used more effectively than with normal search.
In order to do so the
I very strongly suspsect that Many Faces, Mogo, Crazy Stone and others are
heavily optimized to play well on exactly the hardware we have at the
moment.
There is the huge problem that you cannot easily test scalability because
you cannot produce the thousands of game needed to get accurate
-boun...@computer-go.org] *On Behalf Of *terry mcintyre
*Sent:* Wednesday, June 10, 2009 11:04 PM
*To:* computer-go
*Subject:* Re: [computer-go] MCTS, 19x19, hitting a wall?
--
*From:* Don Dailey dailey@gmail.com
My basic observation is that over
But, while that may be the case, perhaps we can say that they are
hitting a wall in their observable playing strength against non-MCTS
players (such as humans) at higher levels. In [2] I touched upon how the
nature of the game changes at higher levels, and how scaling results
obtained
There is no wall, you are just seeing things from too local a
perspective.
When you look at a small gradual slope from a distance, it looks like a
huge mountain and it's easy to overlook the fact that there is a pathway to
the top. That is what we have here, a very long way to the top. We
But here is someting interesting: In the case of computer
chess it has been estimated that the progress in software
has been roughly the same as the progress in hardware.
Modern chess programs are truly amazing, and not just
a result of faster hardware. There is no reason to think
that
steve uurtamo wrote:
But here is someting interesting: In the case of computer
chess it has been estimated that the progress in software
has been roughly the same as the progress in hardware.
Modern chess programs are truly amazing, and not just
a result of faster hardware. There is no
Regarding Moore's Law, I'd love to hear the Mogo team's perspective on this;
they have probably had more opportunity to test their algorithms extensively on
big-n-count computers than any of us.
If I recall correctly, the Huygens supercomputer uses 800 to 3200 cores -- one
to four hundred
There was a huge discussion of this on the computer chess forum.
As it turns out, software and hardware are somewhat intertwined. You would
not write a chess the same way if all you had was a 6502 processor. Most of
the early chess software didn't have the hardware to support hash tables,
so
On Jun 10, 2009, at 12:44 PM, Gian-Carlo Pascutto wrote:
steve uurtamo wrote:
But here is someting interesting: In the case of computer
chess it has been estimated that the progress in software
has been roughly the same as the progress in hardware.
Modern chess programs are truly amazing,
To conclude, it appears that 500 MHz (embedded: poor
cache performance) with little memory for transposition
tables is the lowest you can go, while still staying at grandmaster
level.
that's quite impressive.
some kind of pipelining is involved? are they 32bit?
s.
I believe Fruit is a 32 bit program and glaurung on this platform has been
reworked to be 32 bit.Rybka is a 64 bit program.
There is no question that 64 bit chess programs take a big hit on 32 bit
operating systems.My own program is almost 2X slower on a 32 bit
system. I could probably
Don Dailey wrote:
We do not have a wall, we have a mountain.
Whatever. I'm looking for the ladder to help us up this wall (or the
sledgehammer to knock it down :-), you're looking for ropes to help you
up the mountain.
Darren mentioned that I would say the algorithm is scalable. Apparently
Part of the problem is that we're using global search to play a game
with lots of local little fights. If we have say five little fights, and
each takes say 11 ply to play well, it means a 50 ply global search
just to avoid local blunders.
Currently, we try to sidestep this fundamental
obvious to say it is hard to do right. Searching fights in isolation
misses the interaction between the fights, which is one of the strengths
of MCTS.
Incidentally this interaction between fights plays a bigger part in 9x9
than 19x19, which is perhaps another reason MCTS has done so well on
We ran the 32-core on kgs for a while. I think it was about 1 stone stronger
than the 2 core version. The two core (ManyFaces) is a weak 1 kyu. I think
the 32-core was a weak 1 dan. I don’t remember the account name so I can’t
check the rating.
David Fotland has done quite a bit with a
My basic observation is that over the several year period I have been in
this forum, I have detected a huge amount of resistance to the idea that
hardware could have anything to do with computer go strength, despite the
fact that it keeps proving to be so. The resistance is strong enough that
This is one of two reactions i see repeatedly. The other is to claim
that those who use larger clusters have an unfair advantage and should
be excluded from various competitions ... but we are seeing that one
less often than previously.
As far as i know, i was the first person to use
Mogo-big-4core has been running on the same hardware, Intel core2 quad
Q6600 at 3 GHz, since the beginning. And yes, it's an old version;
MoGo public release with 64 bit value, if I remember correctly.
Hideki
Magnus Persson: 20090610151527.f0nekww928k8g...@webmail.phmp.se:
Hi! Here comes a
26 matches
Mail list logo
