Don, What or who are you fighting to? What do you talking about? I don't catch your point(s).
Hideki Don Dailey: <[email protected]>: >On Thu, Jun 2, 2011 at 12:25 PM, Hideki Kato <[email protected]> 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: <[email protected]>: >> >On Thu, Jun 2, 2011 at 1:08 AM, Hideki Kato <[email protected]> >> wrote: >> > >> >> Michael Williams: <[email protected]>: >> >> >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 <[email protected]> >> >> wrote: >> >> > >> >> >> Although speed matters, the quality of simulations is dominant. When >> >> >> the simulations cannot manage a postion correctly, speed is useless. >> >> >> >> >> >> Hideki >> >> >> >> >> >> Bojun Huang: <[email protected] >> >: >> >> >> >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 <[email protected]> >> >> >> >>To: [email protected] >> >> >> >>Subject: Re: [Computer-go] Direct DX11 and graphics cards for >> cheaper >> >> >> >> simulation hardware? >> >> >> >>Message-ID: [email protected]> >> >> >> >>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 >> >> >> >[email protected] >> >> >> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> >> >> -- >> >> >> Hideki Kato <mailto:[email protected]> >> >> >> _______________________________________________ >> >> >> Computer-go mailing list >> >> >> [email protected] >> >> >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> >> >> >> >> >---- inline file >> >> >_______________________________________________ >> >> >Computer-go mailing list >> >> >[email protected] >> >> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> >> -- >> >> Hideki Kato <mailto:[email protected]> >> >> _______________________________________________ >> >> Computer-go mailing list >> >> [email protected] >> >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> >> >> >---- inline file >> >_______________________________________________ >> >Computer-go mailing list >> >[email protected] >> >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> -- >> Hideki Kato <mailto:[email protected]> >> _______________________________________________ >> Computer-go mailing list >> [email protected] >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> >---- inline file >_______________________________________________ >Computer-go mailing list >[email protected] >http://dvandva.org/cgi-bin/mailman/listinfo/computer-go -- Hideki Kato <mailto:[email protected]> _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
