[computer-go] UEC cup
I was reading a report on the UEC Cup [1] on a (Japanese) blog, and if I understood correctly the results were: 1. Crazy stone 2. Fudogo (?) (Hideki Kato's program) 3. Many Faces 4. Katsunari (Mogo had time trouble and pulled out?) Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? Can anyone post more information? What hardware was Crazy Stone running on? Darren [1]: The home page is here, but no information here yet: http://jsb.cs.uec.ac.jp/~igo/2008/eng/ -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Darren Cook wrote: I was reading a report on the UEC Cup [1] on a (Japanese) blog, and if I understood correctly the results were: 1. Crazy stone 2. Fudogo (?) (Hideki Kato's program) 3. Many Faces 4. Katsunari (Mogo had time trouble and pulled out?) Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? Can anyone post more information? What hardware was Crazy Stone running on? Darren [1]: The home page is here, but no information here yet: http://jsb.cs.uec.ac.jp/~igo/2008/eng/ Crazy Stone was running on the same 8-core PC that won the H8 game of FIT2008. I am waiting impatiently for more information. At least 3 persons who attended sent an email telling that the game was very beautiful, but I don't have a game record yet. MoGo lost because of problems with remote play. This is the info I have: MoGo lost the first game of the final round today by time-out due to the overhead of network delay (via KGS) and the manual input of the moves. It seems that Aya took 5th place. Aya was not lucky with the pairings. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Rémi Coulom: 49461936.2080...@univ-lille3.fr: Darren Cook wrote: I was reading a report on the UEC Cup [1] on a (Japanese) blog, and if I understood correctly the results were: 1. Crazy stone 2. Fudogo (?) (Hideki Kato's program) 3. Many Faces 4. Katsunari 1. Crazy Stone 2. Fudo Go 3. Many Faces of Go 4. Katsunari 5. Aya (Mogo had time trouble and pulled out?) Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? Can anyone post more information? What hardware was Crazy Stone running on? Darren [1]: The home page is here, but no information here yet: http://jsb.cs.uec.ac.jp/~igo/2008/eng/ Crazy Stone was running on the same 8-core PC that won the H8 game of FIT2008. I am waiting impatiently for more information. At least 3 persons who attended sent an email telling that the game was very beautiful, but I don't have a game record yet. MoGo lost because of problems with remote play. This is the info I have: MoGo lost the first game of the final round today by time-out due to the overhead of network delay (via KGS) and the manual input of the moves. It seems that Aya took 5th place. Aya was not lucky with the pairings. Yes, Aya was not lucky and Fudo Go was very lucky. :) The tournament tree after best eight was: CS CS Fudo CSMFG Katsunari Fudo CS* agouti Aya* MFG Katsunari* Gogonomitan RGO Fudo Three stars show seeded programs. Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hideki Kato -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
My understanding of the PlayStation is that it's a Cell architecture, with one main CPU and six auxilary processing units with limited capability. Of course you don't need much for something to do MC playouts, so it seems a very suitable architecture. So 8 PS3s gives a total of 56 CPU's. Plus the four of the desktop that would make 60. I have mixed feelings about this piling up of hardware. On the one hand it's exciting. Complex parallel processing to improve the level of play is very interesting. On the other hand, I hope attention doesn't only go towards putting more computing power together. Mark On 15-dec-08, at 08:23, Darren Cook wrote: Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Rémi Coulom: 49461936.2080...@univ-lille3.fr: Darren Cook wrote: I was reading a report on the UEC Cup [1] on a (Japanese) blog, and if I understood correctly the results were: 1. Crazy stone 2. Fudogo (?) (Hideki Kato's program) 3. Many Faces 4. Katsunari (Mogo had time trouble and pulled out?) Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? Can anyone post more information? What hardware was Crazy Stone running on? Darren [1]: The home page is here, but no information here yet: http://jsb.cs.uec.ac.jp/~igo/2008/eng/ Crazy Stone was running on the same 8-core PC that won the H8 game of FIT2008. I am waiting impatiently for more information. At least 3 persons who attended sent an email telling that the game was very beautiful, but I don't have a game record yet. Following is a _unofficial_ game record. (;FF[4]CA[UTF-8]AP[GoGui:1.1pre3] HA[7]PB[Crazy Stone]PW[Kaori Aoba]RE[B+R] AB[pd][dp][pp][dd][dj][jj][pj]PL[W] EV[The 2nd UEC Cup Exhibition] PC[Univ. of Electro-Communications, Tokyo] ;W[gp];B[dn];W[nq];B[pm];W[jp];B[kg];W[kd];B[hd];W[nc];B[ne] ;W[qf];B[ng];W[qd];B[qc];W[pc];B[oc];W[od];B[pb];W[pe];B[pc] ;W[nd];B[oe];W[nb];B[rd];W[re];B[qe];W[pf];B[rb];W[og];B[me] ;W[id];B[he];W[ld];B[oh];W[qi];B[ic];W[jc];B[ph];W[qj];B[qh] ;W[rm];B[np];W[mp];B[no];W[oq];B[qk];W[rk];B[rh];W[ql];B[pk] ;W[pl];B[ol];W[om];B[nm];W[on];B[nl];W[pn];B[qn];W[qm];B[nn] ;W[op];B[oo];W[po];B[qo];W[pm];B[qq];W[rn];B[ro];W[sl];B[mq] ;W[mr];B[lq];W[lr];B[kq];W[qr];B[jq];W[pq];B[dh];W[iq];B[ib] ;W[ie];B[if];W[jb];B[ko];W[dl];B[gl];W[fm];B[el];W[ek];B[cl] ;W[fl];B[dk];W[em];B[cm];W[dg];B[df];W[cf];B[eg];W[de];B[cg] ;W[ee];B[ce];W[cd];B[bf];W[dc];B[bd];W[ed];B[je];W[jd];B[fc] ;W[bc];B[cb];W[ad];B[db];W[be];B[gk];W[gf];B[hf];W[gc];B[fd] ;W[eb];B[ec];W[fb];B[hc];W[gb];B[fe];W[bb];B[hq];W[dq];B[cq] ;W[ep];B[eq];W[dr];B[eo];W[fp];B[ip];W[gm];B[il];W[im];B[jm] ;W[jn];B[hm];W[io];B[ir];W[hn];B[er];W[hl];B[cr];W[mg];B[lf] ;W[kj];B[nh];W[ji];B[ef];W[cf];B[gi];W[ij];B[ik];W[km];B[ej] ;W[md];B[jl];W[kl];B[hk];W[kn];B[lo];W[jk];B[ce];W[dd];B[ih] ;W[hi];B[gj];W[hh];B[gh];W[hg];B[ff];W[cf];B[ii];W[ig];B[jh] ;W[jg];B[kh];W[jf];B[li];W[lj];B[hj];W[kf];B[gg];W[ke];B[hp]) Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
On Mon, 2008-12-15 at 09:18 -0200, Mark Boon wrote: My understanding of the PlayStation is that it's a Cell architecture, with one main CPU and six auxilary processing units with limited capability. Of course you don't need much for something to do MC playouts, so it seems a very suitable architecture. So 8 PS3s gives a total of 56 CPU's. Plus the four of the desktop that would make 60. I have mixed feelings about this piling up of hardware. On the one hand it's exciting. Complex parallel processing to improve the level of play is very interesting. On the other hand, I hope attention doesn't only go towards putting more computing power together. Here is how I look at it. We probably wouldn't even have monte-carlo programs if hardware was like it was 30 years ago, or even 10 years ago.A few months ago I was thinking about why it took us so long to discover this Monte Carlo thing and then I realized that it couldn't have happened until recent times. Although it may have been POSSIBLE 10 or 15 years ago to produce something that was similar in strength to what was available, you probably need significant overkill before it seems interesting enough for developers to start experimenting with. So if someone 15 years ago, armed with the same ideas we have now, had started developing such a program, it's likely they would have concluded that it's not feasible. It took quite a bit of discovery and effort to get real strong programs. Lazarus, for example is stronger that the old traditional programs by far on small boards on todays hardware, but had I developed Lazarus on my old pentium 133 I would have come to the tentative conclusion (I never say never) that this was probably another bad idea. Computer chess is another interesting example, because we used the same basic approach back then as we use today. But 40 years ago the conclusion was that search doesn't really work - it won by default because we didn't know anything better. The call went out to abandon this brain dead approach and persuasive arguments were presented (based on the laws of physics and the number of electrons in the universe) that it could never work. So I think we have to embrace the fact that hardware is a part of these kinds of advancements. In fact I have always believe this anyway, the whole idea behind computing is to perform simple and stupid operations very very quickly.It's easy to forget that everything about computing and what is possible is tied to the power of the hardware. There is another school of thought that I somewhat subscribe to and I think you are alluding to, that we have been spoiled by the power and do not look for the most efficient way to do things. I know and agree that this happens, but this is more of an engineering issue. As engineers we must use some imagination because ultimately you need as much imagination and power (both) as possible. This is another angle on the high level language argument, that computers are so fast that it's ok if the software it 20 times slower (which is typical for many high level languages.) I think that has always been an asinine concept because there is never enough computing power to accomplish what you want unless you have a limited imagination. I call this the drunken sailor philosophy (on payday, the sailor wastes his whole paycheck for a single night of instant gratification.) - Don Mark On 15-dec-08, at 08:23, Darren Cook wrote: Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Darren Cook: 49463016.1020...@dcook.org: Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Hello Darren, BTW, I'm not a sensei (Professor) but just a doctor course student of 55 years old :). Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Usual applications can use not 8 but 7 cores in fact because one SPU is used exclusively to protect the secured contents by firmware. PPU is not used for MC simulations but the commnunications over network etc. I used one core of Intel for the client (UCT tree searcher) and other three for internal MC simulators and 8 times 6 SPU's external. Thus, 51 cores are uesd for MC simulations in total. The eight PS3 consoles boosted Fudo Go by, perhaps, 2 or 3 stones (ranks) on 19 x 19. The difference of the performance between 4 and 8 PS3's is clear but I'm not sure all 6 SPU's are working in full duty, though I'll study it soon. My last paper on parallel MCTS has no description about the implementation for Cell BE. I'll submit longer paper in this month but if you want to know the detail of my implementation now, you can have the source code of Fudo-Go-2nd-UEC-Cup version, which is exactly what I used for the tournament. http://www.geocities.jp/hideki_katoh/release/fudo-go-2nd-uec-cup.tar.gz Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] I will build a site for the Reference Bots, Specs, and hard data concerning them.
Hi, do you know? http://ricoh51.free.fr/go/engineeng.htm Whats about a wiki? You know sensei lib and friends? Greets WSK - Original Message - From: Denis fidaali To: computer-go@computer-go.org Sent: Monday, November 24, 2008 5:03 PM Subject: [computer-go] I will build a site for the Reference Bots, Specs, and hard data concerning them. Hi. I feel like it's a shame not to publicize anything on all this Reference bot work that has been done. So in the coming days, i'll do my best to get a web-site up and running for it. It probably will be plain html. I have absolutely no design skill, so it may be a bit flat. I'm open to all suggestions concerning what i should put on this site. I think that it would be better to also put there as much useful web-links as we can think of. The planned url for this project is www.computer-go.net Obviously there will be a link to this mailing list Archives. I'm also open to any submissions that would be less than 2Megabyte (assuming there won't be that many). You can mail them to this email. I have full control of the web-site, so it probably is possible to set-up a git repository. Although i have just no idea how to do that. Thanks in advance for any suggestion/advice/.css that might help me get this project on track :) -- Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! -- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] UEC cup
Well, Amen! As Don Dailey said, researchers probably would have concluded that MC was not worth doing, if they had been using the computers of ten or fifteen years back. Looking forward, computer power equivalent to that rig lashed together with 8 PS3s or GPUs or FPGAs, or some combination thereof, will be available on your desktop in ten or fifteen years. Last year, a quadcore cost about $800; this year, the price is about half that. Intel and AMD roadmaps show 6- and 8-core computers coming soon. Apple is working on Open CL, which could it make it easier to tap the GPU. Tesla GPU boards are within the budget of many researchers. The algorithms which best exploit the power of large clusters - especially of non-von Neumann architectures - have yet to be discovered. I'm glad researchers are experimenting with funky clusters to improve Go programs. Lots of variation and selective pressure can only improve the state of the art. If somebody wins all the tournaments, others must tweak their parameters and optimize their code to stay in the game. David Fotland recently spent six months doing a great deal of work to improve Many Faces of Go, grafting MC-based code to his traditional-style engine. His program advanced four or five kyu. If MC programs were not winning competitions, would he have put in all that time and effort? Mr Fotland is now tweaking his program to scale well on n32 processors - could he be thinking about Moore's Law bringing manycore computers within reach of more and more enthusiasts within a decade? The Mogo team and others are likewise using as much computer power as they can; more power to them! IBM once spent a million dollars to build Deep Blue, which beat Kasparov in the game of Chess. Today, I suspect that an ordinary quadcore with a top program could play as well. Here's hoping that, in a decade or two, our newest desktops play a pro-level game of Go. I'm hoping that some research departments think of these projects as a good way to train today's students to wrap their brains around the task of developing for manycore architectures. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] UEC cup
I was in Japan for a year in 1990. I was 1k - 1d EGF at that time and i was 4d in Japan. I think the grade difference between EGF and Japan is more like 3 grades than 2 grades. I also participated in a Japan-Netherlands friendship match by the Japanese Embassy in Holland. We played against Japanese players with full handicap but our grades were increased by 3. At that time I was a 3d EFG but I had to give handicap as a 6d Japanese. The match was won by Holland with big numbers even with the 3 grades correction. Also, a 4p is not a 7p. The difference should be about one stone. 4p is equivalent to 8d EGF. So i would say winning with seven stones against a 4p suggests that Crazy stone is about 1d - 2d. This is similar to the result achieved by Mogo. Dave Van: computer-go-boun...@computer-go.org namens Darren Cook Verzonden: ma 15-12-2008 9:34 Aan: computer-go Onderwerp: [computer-go] UEC cup I was reading a report on the UEC Cup [1] on a (Japanese) blog, and if I understood correctly the results were: 1. Crazy stone 2. Fudogo (?) (Hideki Kato's program) 3. Many Faces 4. Katsunari (Mogo had time trouble and pulled out?) Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? Can anyone post more information? What hardware was Crazy Stone running on? Darren [1]: The home page is here, but no information here yet: http://jsb.cs.uec.ac.jp/~igo/2008/eng/ -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Kato, have you compared the speed of the simulations on PS3 SPE to the speed of the simulations on PC, given that the program is optimized for the cpu on both sides. On Mon, Dec 15, 2008 at 6:40 AM, Hideki Kato hideki_ka...@ybb.ne.jp wrote: Darren Cook: 49463016.1020...@dcook.org: Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Hello Darren, BTW, I'm not a sensei (Professor) but just a doctor course student of 55 years old :). Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Usual applications can use not 8 but 7 cores in fact because one SPU is used exclusively to protect the secured contents by firmware. PPU is not used for MC simulations but the commnunications over network etc. I used one core of Intel for the client (UCT tree searcher) and other three for internal MC simulators and 8 times 6 SPU's external. Thus, 51 cores are uesd for MC simulations in total. The eight PS3 consoles boosted Fudo Go by, perhaps, 2 or 3 stones (ranks) on 19 x 19. The difference of the performance between 4 and 8 PS3's is clear but I'm not sure all 6 SPU's are working in full duty, though I'll study it soon. My last paper on parallel MCTS has no description about the implementation for Cell BE. I'll submit longer paper in this month but if you want to know the detail of my implementation now, you can have the source code of Fudo-Go-2nd-UEC-Cup version, which is exactly what I used for the tournament. http://www.geocities.jp/hideki_katoh/release/fudo-go-2nd-uec-cup.tar.gz Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Fw: IEEE Spectrum Online: How We Found the Missing Memristor
This could be the future of computer Go: fast, dense, nonvolatile RAM; fast and dense FPGAs, and direct models of neurons as memristor devices. - Forwarded Message Most Read Content Top 3 most read articles: * How We Found the Missing Memristor * Slideshow: Meet the Universe's Ultimate Engineers * Slideshow: Tabletop Computers Most Emailed Content Top 3 most emailed articles: * How We Found the Missing Memristor * The Exterminators * Idiot-proofing the Defibrillator Top Editor's Choice Articles Editor's Top 3 picks * RD Goes Global * The Weapons Acquisition Process: An Intellectual Disconnect * New Class of Digital Signal Processor Wipes Out Wasted Power How We Found the Missing Memristor The memristor--the functional equivalent of a synapse--could revolutionize circuit design Read the full article at: http://spectrum.ieee.org/dec08/7024 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
On Mon, Dec 15, 2008 at 12:37 PM, Don Dailey drdai...@cox.net wrote: So I think we have to embrace the fact that hardware is a part of these kinds of advancements. In fact I have always believe this anyway, the whole idea behind computing is to perform simple and stupid operations very very quickly.It's easy to forget that everything about computing and what is possible is tied to the power of the hardware. There is another school of thought that I somewhat subscribe to and I think you are alluding to, that we have been spoiled by the power and do not look for the most efficient way to do things. That is another matter, one that I agree with. But that was not what I was alluding to. If anything, the fact that MC programs are highly scalable puts much more focus on efficient algorithms than has been the case in prior years. As with any IT problem, Computer-Go is both about hardware and software. I have no problem with that, it's the nature of computers and software. What I was alluding to was that I hope the software doesn't take a back-seat to the increase of hardware. I don't think it's nearly as interesting if it becomes a competition of who can bring the biggest piece of iron or who can arrange the biggest sponsor to pay for hardware (which is a bit what happened with Deep Blue). In the meantime, I think the advances that MC programs have brought are great. And so is the attention the matches get when playing against a pro with a super-computer. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
From: Mark Boon tesujisoftw...@gmail.com On Mon, Dec 15, 2008 at 12:37 PM, Don Dailey wrote: So I think we have to embrace the fact that hardware is a part of these kinds of advancements. In fact I have always believe this anyway, the whole idea behind computing is to perform simple and stupid operations very very quickly.It's easy to forget that everything about computing and what is possible is tied to the power of the hardware. There is another school of thought that I somewhat subscribe to and I think you are alluding to, that we have been spoiled by the power and do not look for the most efficient way to do things. That is another matter, one that I agree with. But that was not what I was alluding to. If anything, the fact that MC programs are highly scalable puts much more focus on efficient algorithms than has been the case in prior years. As with any IT problem, Computer-Go is both about hardware and software. I have no problem with that, it's the nature of computers and software. What I was alluding to was that I hope the software doesn't take a back-seat to the increase of hardware. I don't think it's nearly as interesting if it becomes a competition of who can bring the biggest piece of iron or who can arrange the biggest sponsor to pay for hardware (which is a bit what happened with Deep Blue). In the meantime, I think the advances that MC programs have brought are great. And so is the attention the matches get when playing against a pro with a super-computer. In my experience with IT systems administration, people do tend to let the hardware do the heavy lifting when algorithmic improvements could double and quadruple the performance. We don't know much about the space of useful algorithms; if we focus on some particular algorithm, we may only be able to wring a few percent out of it, where some better algorithm could possibly yield 50% or 75% reduction in run time. We are looking for higher peaks on a mountain range enshrouded by a heavy fog of uncertainty. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] RefBot (thought-) experiments
Hi. This is a continuation of a month-old conversation about the possibility that the quality of AMAF Monte Carlo can degrade, as the number of simulations increases: Me: running 10k playouts can be significantly worse than running 5k playouts. On Tue, Nov 18, 2008 at 2:27 PM, Don Dailey drdai...@cox.net wrote: On Tue, 2008-11-18 at 14:17 -0500, Weston Markham wrote: On Tue, Nov 18, 2008 at 12:02 PM, Michael Williams michaelwilliam...@gmail.com wrote: It doesn't make any sense to me from a theoretical perspective. Do you have empirical evidence? I used to have data on this, from a program that I think was very nearly identical to Don's reference spec. When I get a chance, I'll try to reproduce it. Unless the difference is large, you will have to run thousands of games to back this up. - Don I am comparing the behavior of the AMAF reference bot with 5000 playouts against the behavior with 10 playouts, and I am only considering the first ten moves (five from each player) of the (9x9) games. I downloaded a copy of Don's reference bot, as well as a copy of Mogo, which is used as an opponent for each of the two settings. gnugo version 3.7.11 is also used, in order to judge which side won (jrefgo or mogo) after each individual match. gnugo was used because it is simple to set it up for this sort of thing via command-line options, and it seems plausible that it should give a somewhat realistic assessment of the situation. jrefgo always plays black, and Mogo plays white. Komi is set to 0.5, so that jrefgo has a reasonable number of winning lines available to it, although the general superiority of Mogo means that egregiously bad individual moves will be punished. In the games played, Mogo would occasionally crash. (This was run under Windows Vista; perhaps there is some incompatibility of the binary I downloaded) I have discarded these games (about 1 out of 50, I think) from the statistics gathered. As far as I know, there would be no reason to think that this would skew the comparison between 5k playouts and 100k playouts. Other than occasional crashes, the behavior of Mogo seemed reasonable in other games that I observed. I have no reason to think that it was not playing at a relatively high level in the retained results. Out of 3637 matches using 5k playouts, jrefgo won (i.e., was ahead after 10 moves, as estimated by gnugo) 1688 of them. (46.4%) Out of 2949 matches using 100k playouts, jrefgo won 785. (26.6%) It appears clear to me that increasing the number of playouts from 5k to 100k certainly degrades the performance of jrefgo. Below, I am including the commands that I used to run the tests and tally the results. Weston $ cat scratch5k.sh ../gogui-1.1.3/bin/gogui-twogtp -auto -black \C:Program FilesJavaj dk1.6.0_06binjava.exe\ -jar jrefgo.jar 5000 -games 1 -komi 0.5 -ma xmoves 10 -referee gnugo --mode gtp --score aftermath --chinese-rules --positio nal-superko -sgffile games/jr5k-v-mogo -size 9 -white C:cygwinhomeE xperienceprojectsgoMoGo_release3mogo.exe $ grep B+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1688 $ grep W+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1949 $ grep B+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 785 $ grep W+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 2164 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
On Mon, 2008-12-15 at 14:22 -0800, terry mcintyre wrote: In my experience with IT systems administration, people do tend to let the hardware do the heavy lifting when algorithmic improvements could double and quadruple the performance. We don't know much about the space of useful algorithms; if we focus on some particular algorithm, we may only be able to wring a few percent out of it, where some better algorithm could possibly yield 50% or 75% reduction in run time. We are looking for higher peaks on a mountain range enshrouded by a heavy fog of uncertainty. That may be true of IT system administrators, but game developers writing extremely high performance game playing programs like Go and Chess don't think like that at all. They do not blow off even minor performance improvements. They salivate when new hardware comes out, and it's not because they can switch over to slower algorithms or use higher level languages. To these kind of people that would be like buying a brand new Lamborghini for driving to the grocery store. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] RefBot (thought-) experiments
Is Jrefgo the pure version that does not use tricks like the futures map? If you use things like that, all bets are off - I can't be sure this is not negatively scalable. You cannot draw any reasonable conclusions by stopping after 10 moves and letting gnugo judge the game either.Why didn't you play complete games? - Don On Mon, 2008-12-15 at 17:30 -0500, Weston Markham wrote: Hi. This is a continuation of a month-old conversation about the possibility that the quality of AMAF Monte Carlo can degrade, as the number of simulations increases: Me: running 10k playouts can be significantly worse than running 5k playouts. On Tue, Nov 18, 2008 at 2:27 PM, Don Dailey drdai...@cox.net wrote: On Tue, 2008-11-18 at 14:17 -0500, Weston Markham wrote: On Tue, Nov 18, 2008 at 12:02 PM, Michael Williams michaelwilliam...@gmail.com wrote: It doesn't make any sense to me from a theoretical perspective. Do you have empirical evidence? I used to have data on this, from a program that I think was very nearly identical to Don's reference spec. When I get a chance, I'll try to reproduce it. Unless the difference is large, you will have to run thousands of games to back this up. - Don I am comparing the behavior of the AMAF reference bot with 5000 playouts against the behavior with 10 playouts, and I am only considering the first ten moves (five from each player) of the (9x9) games. I downloaded a copy of Don's reference bot, as well as a copy of Mogo, which is used as an opponent for each of the two settings. gnugo version 3.7.11 is also used, in order to judge which side won (jrefgo or mogo) after each individual match. gnugo was used because it is simple to set it up for this sort of thing via command-line options, and it seems plausible that it should give a somewhat realistic assessment of the situation. jrefgo always plays black, and Mogo plays white. Komi is set to 0.5, so that jrefgo has a reasonable number of winning lines available to it, although the general superiority of Mogo means that egregiously bad individual moves will be punished. In the games played, Mogo would occasionally crash. (This was run under Windows Vista; perhaps there is some incompatibility of the binary I downloaded) I have discarded these games (about 1 out of 50, I think) from the statistics gathered. As far as I know, there would be no reason to think that this would skew the comparison between 5k playouts and 100k playouts. Other than occasional crashes, the behavior of Mogo seemed reasonable in other games that I observed. I have no reason to think that it was not playing at a relatively high level in the retained results. Out of 3637 matches using 5k playouts, jrefgo won (i.e., was ahead after 10 moves, as estimated by gnugo) 1688 of them. (46.4%) Out of 2949 matches using 100k playouts, jrefgo won 785. (26.6%) It appears clear to me that increasing the number of playouts from 5k to 100k certainly degrades the performance of jrefgo. Below, I am including the commands that I used to run the tests and tally the results. Weston $ cat scratch5k.sh ../gogui-1.1.3/bin/gogui-twogtp -auto -black \C:Program FilesJavaj dk1.6.0_06binjava.exe\ -jar jrefgo.jar 5000 -games 1 -komi 0.5 -ma xmoves 10 -referee gnugo --mode gtp --score aftermath --chinese-rules --positio nal-superko -sgffile games/jr5k-v-mogo -size 9 -white C:cygwinhomeE xperienceprojectsgoMoGo_release3mogo.exe $ grep B+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1688 $ grep W+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1949 $ grep B+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 785 $ grep W+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 2164 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
From: Don Dailey drdai...@cox.net On Mon, 2008-12-15 at 14:22 -0800, terry mcintyre wrote: In my experience with IT systems administration, people do tend to let the hardware do the heavy lifting when algorithmic improvements could double and quadruple the performance. We don't know much about the space of useful algorithms; if we focus on some particular algorithm, we may only be able to wring a few percent out of it, where some better algorithm could possibly yield 50% or 75% reduction in run time. We are looking for higher peaks on a mountain range enshrouded by a heavy fog of uncertainty. That may be true of IT system administrators, but game developers writing extremely high performance game playing programs like Go and Chess don't think like that at all. They do not blow off even minor performance improvements. They salivate when new hardware comes out, and it's not because they can switch over to slower algorithms or use higher level languages. To these kind of people that would be like buying a brand new Lamborghini for driving to the grocery store. A more apt analogy might be driving that brand new Lamborghini the long and twisty way around the country, instead of using a more direct route, given that you don't have an accurate map. You're going faster, but not getting as much speedup as possible. We're a long way from knowing the best possible algorithms to solve this problem. We may even need to make radical revisions to take advantage of totally different architectures. If, for example, large-scale memristor networks are developed, we might find that they can do an amazing amount of work compared to von Neumann architectures. We might stop thinking of CPUs and memory as separate entities. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] RefBot (thought-) experiments
Weston, Although those result sound intriguing, it also looks like a convoluted experiment. I wouldn't call gnu-go an expert judge, although it is an impartial one. The fact that it says that the 5K ref-bot is ahead after 10 moves 46% of the time alone makes it suspect in my eyes. But it is curious it consistently shows a much lower percentage for the bot with more playouts. It would have been much more persuasive if you had simply run a 5K playout bot against a 100K bot and see which wins more. It shouldn't take much more than a day to gather a significant number of games. twogtp is perfect for this. Or connect both to CGOS and see which ends up with a higher rating. But in that case it will take a week or more before you get conclusive data. Unless the difference is really clear. I did in fact put up a 100K+ ref-bot on CGOS for a little while, and it ended up with a rating slightly (possibly insignificantly) higher than the 2K ref-bot. Maybe I didn't put it there long enough, certainly not for thousands of games. But it didn't look anywhere near to supporting your findings. I say 100K+ because I didn't set it to a specific number, just run as many as it could within time allowed. Generally it would reach well over 100K per move, probably more like 250K-500K. That should only make things worse according to your hypothesis. So although I think the result of your experiment is very curious, I think it might be a bit hasty draw your conclusion. Mark On Mon, Dec 15, 2008 at 8:30 PM, Weston Markham weston.mark...@gmail.com wrote: Hi. This is a continuation of a month-old conversation about the possibility that the quality of AMAF Monte Carlo can degrade, as the number of simulations increases: Me: running 10k playouts can be significantly worse than running 5k playouts. On Tue, Nov 18, 2008 at 2:27 PM, Don Dailey drdai...@cox.net wrote: On Tue, 2008-11-18 at 14:17 -0500, Weston Markham wrote: On Tue, Nov 18, 2008 at 12:02 PM, Michael Williams michaelwilliam...@gmail.com wrote: It doesn't make any sense to me from a theoretical perspective. Do you have empirical evidence? I used to have data on this, from a program that I think was very nearly identical to Don's reference spec. When I get a chance, I'll try to reproduce it. Unless the difference is large, you will have to run thousands of games to back this up. - Don I am comparing the behavior of the AMAF reference bot with 5000 playouts against the behavior with 10 playouts, and I am only considering the first ten moves (five from each player) of the (9x9) games. I downloaded a copy of Don's reference bot, as well as a copy of Mogo, which is used as an opponent for each of the two settings. gnugo version 3.7.11 is also used, in order to judge which side won (jrefgo or mogo) after each individual match. gnugo was used because it is simple to set it up for this sort of thing via command-line options, and it seems plausible that it should give a somewhat realistic assessment of the situation. jrefgo always plays black, and Mogo plays white. Komi is set to 0.5, so that jrefgo has a reasonable number of winning lines available to it, although the general superiority of Mogo means that egregiously bad individual moves will be punished. In the games played, Mogo would occasionally crash. (This was run under Windows Vista; perhaps there is some incompatibility of the binary I downloaded) I have discarded these games (about 1 out of 50, I think) from the statistics gathered. As far as I know, there would be no reason to think that this would skew the comparison between 5k playouts and 100k playouts. Other than occasional crashes, the behavior of Mogo seemed reasonable in other games that I observed. I have no reason to think that it was not playing at a relatively high level in the retained results. Out of 3637 matches using 5k playouts, jrefgo won (i.e., was ahead after 10 moves, as estimated by gnugo) 1688 of them. (46.4%) Out of 2949 matches using 100k playouts, jrefgo won 785. (26.6%) It appears clear to me that increasing the number of playouts from 5k to 100k certainly degrades the performance of jrefgo. Below, I am including the commands that I used to run the tests and tally the results. Weston $ cat scratch5k.sh ../gogui-1.1.3/bin/gogui-twogtp -auto -black \C:Program FilesJavaj dk1.6.0_06binjava.exe\ -jar jrefgo.jar 5000 -games 1 -komi 0.5 -ma xmoves 10 -referee gnugo --mode gtp --score aftermath --chinese-rules --positio nal-superko -sgffile games/jr5k-v-mogo -size 9 -white C:cygwinhomeE xperienceprojectsgoMoGo_release3mogo.exe $ grep B+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1688 $ grep W+ games/jr5k-v-mogo.dat | grep -v unexp | wc -l 1949 $ grep B+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 785 $ grep W+ games/jr100k-v-mogo.dat | grep -v unexp | wc -l 2164
Re: [computer-go] UEC cup
big numbers even with the 3 grades correction. Also, a 4p is not a 7p. The difference should be about one stone. 4p is equivalent to 8d EGF. So i would say winning with seven stones against a 4p suggests that Crazy stone is about 1d - 2d. This is similar to the result achieved by Mogo. Though on less hardware (8 cores instead of hundreds). However I think the rank may be even lower - I took the 4 or 5 dan from the blog article without thinking, but you're right, pro ranks are about 1/3 of a handicap stone, so 4p would be roughly 8d, giving us 1-2 dan Japanese, or 1kyu-ish European. (Perhaps the 4 or 5 dan grade was based on the audience's opinion from watching the game? I.e. perhaps they thought it would still have won given a lower handicap?) Darren Crazy stone then played against Kaori Aoba, 4p, at a 7-stone handicap and won by resignation. Making crazy stone 4 or 5 dan, by Japanese standards. Maybe 2-3 dan European? -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
On Mon, 2008-12-15 at 14:51 -0800, terry mcintyre wrote: From: Don Dailey drdai...@cox.net On Mon, 2008-12-15 at 14:22 -0800, terry mcintyre wrote: In my experience with IT systems administration, people do tend to let the hardware do the heavy lifting when algorithmic improvements could double and quadruple the performance. We don't know much about the space of useful algorithms; if we focus on some particular algorithm, we may only be able to wring a few percent out of it, where some better algorithm could possibly yield 50% or 75% reduction in run time. We are looking for higher peaks on a mountain range enshrouded by a heavy fog of uncertainty. That may be true of IT system administrators, but game developers writing extremely high performance game playing programs like Go and Chess don't think like that at all. They do not blow off even minor performance improvements. They salivate when new hardware comes out, and it's not because they can switch over to slower algorithms or use higher level languages. To these kind of people that would be like buying a brand new Lamborghini for driving to the grocery store. A more apt analogy might be driving that brand new Lamborghini the long and twisty way around the country, instead of using a more direct route, given that you don't have an accurate map. You're going faster, but not getting as much speedup as possible. We're a long way from knowing the best possible algorithms to solve this problem. We may even need to make radical revisions to take advantage of totally different architectures. If, for example, large-scale memristor networks are developed, we might find that they can do an amazing amount of work compared to von Neumann architectures. We might stop thinking of CPUs and memory as separate entities. It is true that we don't know the best possible algorithm for solving this problem, but that has nothing to do with letting the hardware do the heavy lifting. What I'm saying is that High Performance game developers are totally focused on squeezing as much performance as possible out of the software. I don't just mean brute force power but every kind of elegant performance improvement. I don't like your Lamborghini analogy. My analogy was designed to be about waste, taking something beautiful and using it in some mundane way. Maybe my point would have been clearer if I had said that I was buying a brand new Lamborghini to haul cow manure instead of using my work truck. Your analogy is about enjoying the machine for what it was intended for. So if you gave me a computer 50X faster than what I have now, I could rewrite Lazarus in Ruby instead of C and it would run roughly like it does now. I don't view that as a very intelligent use of such a hypothetical and wonderful machine. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Go Fast: d71be7350812150948v45d23e4bn8b4cdd7670839...@mail.gmail.com: Kato, have you compared the speed of the simulations on PS3 SPE to the speed of the simulations on PC, given that the program is optimized for the cpu on both sides. I've published the comparison in A Study on Implementing Parallel MC/UCT Algorithm (in Japanese) http://www.geocities.jp/hideki_katoh/publications/gpw2007/gpw07-private.pdf at GPW 2007. Following is a part of Table 1 on page 4 (modified). CPU TimekppsRatio Cell830 us 1.2 1 x86 163 us 6.1 5.1 Cell runs about five times slower than x86 with almost the same clock (3.18 vs. 3.0 GHz), which is much slower than expected due to my not-optimized-for-SPU code, ie, the same C code was used. If I remember correctly, byte access on Cell is 3 to 7 times slower than x86 because SPU has only 16 byte load/store instructions. Watching generated code, loading a byte is simulated by: mask the lower 4 bit of the address, load 16 bytes, shift and mask the data to place the target byte at right most byte in the register. Thus, 4 instructions are needed for every byte fetch. Storing a byte is more complex: mask, shift, mask the address, load the 16 byte that includes the byte to another register, mask, merge, store-back the whole 16 bytes. I've implemented bitboard representation for 9 x 9 board for both processors, which is thought to best match SPU's 128 128-bit-wide general registers. Due to short of time, I've not compared the simulation speed but just the execution time of final_score() function using flood-fill algorithm with the general registers on SPU and SSE (128-bit wide) registers on x86. The result was almost the same (Cell was faster 5% or less). I will rewrite the MC simulator using bitboard on SPU but I have no time right now... :( Hideki On Mon, Dec 15, 2008 at 6:40 AM, Hideki Kato hideki_ka...@ybb.ne.jp wrote: Darren Cook: 49463016.1020...@dcook.org: Advertisement: Fudo Go used a desktop pc (Intel Q9550) and _eight_ Playstation 3 consoles on a private Gigabit Ethernet LAN. Hello Kato-sensei, Hello Darren, BTW, I'm not a sensei (Professor) but just a doctor course student of 55 years old :). Are you able to use all 8 cores of the playstation? So, with the 4 of the Q9550, 68 cores altogether? Do you, or your students, have any papers on the hardware challenges/solutions? Usual applications can use not 8 but 7 cores in fact because one SPU is used exclusively to protect the secured contents by firmware. PPU is not used for MC simulations but the commnunications over network etc. I used one core of Intel for the client (UCT tree searcher) and other three for internal MC simulators and 8 times 6 SPU's external. Thus, 51 cores are uesd for MC simulations in total. The eight PS3 consoles boosted Fudo Go by, perhaps, 2 or 3 stones (ranks) on 19 x 19. The difference of the performance between 4 and 8 PS3's is clear but I'm not sure all 6 SPU's are working in full duty, though I'll study it soon. My last paper on parallel MCTS has no description about the implementation for Cell BE. I'll submit longer paper in this month but if you want to know the detail of my implementation now, you can have the source code of Fudo-Go-2nd-UEC-Cup version, which is exactly what I used for the tournament. http://www.geocities.jp/hideki_katoh/release/fudo-go-2nd-uec-cup.tar.gz Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ inline file ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UEC cup
Hideki Kato: 494641e9.9402%hideki_ka...@ybb.ne.jp: snip My last paper on parallel MCTS has no description about the implementation for Cell BE. I'll submit longer paper in this month but if you want to know the detail of my implementation now, you can have the source code of Fudo-Go-2nd-UEC-Cup version, which is exactly what I used for the tournament. http://www.geocities.jp/hideki_katoh/release/fudo-go-2nd-uec-cup.tar.gz All symbolic links in above archive was broken. Please download again. Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
