[Computer-go] Direct DX11 and graphics cards for cheaper simulation hardware?

Don Dailey dailey.don at gmail.com
Thu Jun 2 10:10:52 PDT 2011


On Thu, Jun 2, 2011 at 12:25 PM, Hideki Kato <hideki_katoh at ybb.ne.jp> wrote:

> Don,
>
> I'm discussing not general cases but _such_ case where simulations
> return wrong results (for a position).  In that case, speed is
> useless.
>

Simulations almost always return the wrong results just like the chess
evaluation function always returns a crude approximation and quite often a
downright flawed evaluation.

But I guess I don't understand the point being made or else it's so obvious
that I read more into it that was intended.     I completely agree that
simulations often return the wrong results and that better playouts return
much more accurate results and that some position are really hard and some
are much easier, etc.   But this has to be going somewhere and I guess I
don't understand where that is.

Are you trying to say that heavy playouts are better?   Who is going to
argue with that?    I agree completely.    Are you trying to make the point
that there are very simple to understand positions that computers cannot
easily solve?   I agree with that.   Are you trying to say that heavy
playouts can solve many types of common positions orders or magnitude faster
than light playouts?   I agree with that.    Are you trying to say uniformly
random playouts suck?    I agree with that.

Is there some point we actually disagree on?    This feels like a debate,
but nobody is coming right out and telling me what it is they are in
disagreement of.    Instead I'm being challenged with examples of difficult
to solve positions that are easy for humans - but with no clue about what
point this is supposed to be refuting.









>
> Hideki
>
> Don Dailey: <BANLkTimC1UpjN9cOARvYTdaNatJKUu_fMQ at mail.gmail.com>:
> >On Thu, Jun 2, 2011 at 1:08 AM, Hideki Kato <hideki_katoh at ybb.ne.jp>
> wrote:
> >
> >> Michael Williams: <BANLkTik1aLhHh738mbYMvYQgRU_VYULugA at mail.gmail.com>:
> >> >Well, not literally useless, as long as you are building a tree equally
> >> >fast.
> >>
> >> Well, but the tree is expanded in a wrong direction, which is also
> >> useless, isn't it?
> >> #I'd like to agree to add "almost" is literally correct but I believe
> >> that speed is really useless in that case.   It's unknown if expanding
> >> tree in wrong directions helps.  According to the convergence theorem of
> >> UCT, I bet this does not help becaues the simulations return wrong
> >> results.
> >>
> >
> >I don't understand your concept of "wrong direction."    When you expand
> the
> >tree for ANY move you get more information about how good or how bad that
> >move is,  so it's always helpful (on average) to have more time.
> >
> >Of course it's true that you want the highest quality play-outs but it
> >doesn't follow that extra time doesn't help,  it always helps.     I think
> >all simulations return the "wrong results"  in many positions and that's
> why
> >there is a tree in the first place.    Uniform random play-outs return a
> >less accurate picture but it's still correlated roughly with winning and
> >losing.
> >
> >Many times we make the mistake of trying to turn gray into black and
> >white because it's often easier to think about that way.     There were
> >numerous examples of that in what you said,  for example:  "return wrong
> >results" should be "often returns wrong results" and "wrong direction" I
> >think you should have said, "tends to expand less relevant parts of the
> >tree"  and "useless" should be "of less value."
> >
> >
> >
> >
> >>
> >> Hideki
> >>
> >> >On Wed, Jun 1, 2011 at 8:13 PM, Hideki Kato <hideki_katoh at ybb.ne.jp>
> >> wrote:
> >> >
> >> >> Although speed matters, the quality of simulations is dominant.  When
> >> >> the simulations cannot manage a postion correctly, speed is useless.
> >> >>
> >> >> Hideki
> >> >>
> >> >> Bojun Huang: <433dfa50.10679.1304ba7a117.Coremail.huang_b_j at 163.com
> >:
> >> >> >It seems to me that, there is a thread of efforts that try to
> improve
> >> the
> >> >> playing capability
> >> >> >of GO bots by dramatically increasing playouts/sec. Now we know that
> >> FPGA,
> >> >> GPU, and SIMD can
> >> >> >make much more playouts per second than single-core CPU, but all
> these
> >> >> results are based on
> >> >> >"light" playout schemes. So everytime when these kind of results
> come
> >> out,
> >> >> people would doubt
> >> >> >the likelihood that these designs really generate strong programs.
> >> >> >
> >> >> >So my question is, Is there a "widely accepted" baseline performance
> to
> >> >> compare with for all
> >> >> >these works?
> >> >> >
> >> >> >For example, we may pick a known program with "lightest" playout
> scheme
> >> >> among those
> >> >> >frequently attending the KGS monthly. So if a high-performance
> design
> >> >> implements similar
> >> >> >playout scheme of that program but achieves much higher playout/sec,
> we
> >> >> could reasonably
> >> >> >expect a stronger program based on this design.
> >> >> >
> >> >> >Another question ... does more playouts really provide a
> *consistent*
> >> >> improvement on the ELO
> >> >> >score, especially for those strongest programs? I remember that some
> >> >> programs running on
> >> >> >laptop rank very high in the Olympaids, that seems imply that speed
> >> simply
> >> >> doesn't matter
> >> >> >here ...
> >> >> >
> >> >> >Thanks,
> >> >> >Bojun Huang
> >> >> >
> >> >> >>Date: Wed, 25 May 2011 22:23:29 +0200
> >> >> >>From: Antoine de Maricourt <antoine.de-maricourt at m4x.org>
> >> >> >>To: computer-go at dvandva.org
> >> >> >>Subject: Re: [Computer-go] Direct DX11 and graphics cards for
> cheaper
> >> >> >>      simulation hardware?
> >> >> >>Message-ID: 4DDD6541.5070003 at m4x.org>
> >> >> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >> >> >>
> >> >> >>
> >> >> >>> Despite the challenges using it in a tree, and the contentious
> issue
> >> of
> >> >> >>> whether light playouts can make a really strong program, I think
> >> this
> >> >> is
> >> >> >>> interesting research. By 1.6 times quicker than libego, do you
> mean
> >> as
> >> >> >>> it runs on the CPU? Or is this a simulated speed as if it was
> >> running
> >> >> on
> >> >> >>> the GPU? I think libego was the clear leader in light playout
> speed,
> >> so
> >> >> >>> working out a way to do playouts even faster (if that is what you
> >> have
> >> >> >>> done) is amazing.
> >> >> >>I just emulated data structures and algorithms that are targeting
> GPU
> >> >> >>in C++ for a CPU. 128-bit CPU's SIMD instruction set simply
> emulates 4
> >> >> >>GPU-like threads working on 32-bit registers. After several
> attempts
> >> >> >>made to test various ideas, the first complete implementation had
> >> >> >>performances similar to libego, without a simple CPU specific
> >> >> >>optimization. I then put back some specific CPU optimizations (not
> >> >> >>likely to be effective on GPU) + tuning and easily improved the
> >> >> >>performances. This is really how it runs on the CPU. The same data
> >> >> >>structure and algorithm is likely to have an even better ratio
> against
> >> >> >>libego with an AVX enabled processor.
> >> >> >>
> >> >> >>Light playout was a beginning to start with. The random move
> generator
> >> >> >>has been designed to take into account a probability distribution
> >> (with
> >> >> >>a little slowdown) that can be derived from local pattern matching.
> >> >> >>
> >> >> >>Regards,
> >> >> >>
> >> >> >>     Antoine
> >> >> >---- inline file
> >> >> >_______________________________________________
> >> >> >Computer-go mailing list
> >> >> >Computer-go at dvandva.org
> >> >> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> >> >> --
> >> >> Hideki Kato <mailto:hideki_katoh at ybb.ne.jp>
> >> >> _______________________________________________
> >> >> Computer-go mailing list
> >> >> Computer-go at dvandva.org
> >> >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> >> >>
> >> >---- inline file
> >> >_______________________________________________
> >> >Computer-go mailing list
> >> >Computer-go at dvandva.org
> >> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> >> --
> >> Hideki Kato <mailto:hideki_katoh at ybb.ne.jp>
> >> _______________________________________________
> >> Computer-go mailing list
> >> Computer-go at dvandva.org
> >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> >>
> >---- inline file
> >_______________________________________________
> >Computer-go mailing list
> >Computer-go at dvandva.org
> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> --
> Hideki Kato <mailto:hideki_katoh at ybb.ne.jp>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20110602/863360a1/attachment.html>


More information about the Computer-go mailing list