Re: [computer-go] Big board. Torus ?
On Wed, Feb 21, 2007 at 07:55:15PM -0600, Matt Gokey wrote: Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter. There can still be subtle differences. In a standard torus, a ladder comes back to its starting point. If you twist the torus enough, it will miss, and fill the whole board... Hardly relevant to random players that don't understand ladders, but anyway... -H -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re[4]: [computer-go] UCT vs MC
One more question. Line 23 states: for i:=node.size()-2 to 0 do. The leaf node should be stored in node[node.size()-1], so why do we start at node.size()-2? Is it not necessary to update the value of the leaf node? i:=node.size()-1 would be better you're right :-). Experiments made by people in this list (Don if I remember correctly), showed that you even don't have to create the leaf if the parent node has less than a few simulations. 100 simulations seemed to be already safe, and much faster. So the modification in the algorithm, is to stop the descend when the number of simulations of the node is threshold rather than ending on a unseen node. Sylvain -Original Message- From: Don Dailey [EMAIL PROTECTED] To: Dmitry Kamenetsky [EMAIL PROTECTED], computer-go computer-go@computer-go.org Date: Wed, 21 Feb 2007 12:54:43 -0500 Subject: Re: Re[2]: [computer-go] UCT vs MC On Wed, 2007-02-21 at 16:56 +0300, Dmitry Kamenetsky wrote: Thank you for your answer. However, I am even more confused now. I understand that - is for negamax, but I don't understand why it became 1-. I am trying to implement your algorithm and I just want to know what lines 7, 16 and 26 should be? I'm not sure this is what you are looking for, but in negamax, scores can be negative or positive. The scores are always adjusted so that you can view positive numbers as good and negative as bad from the point of view you are referencing. So to get the score from the other point of view you simple negate it. But in UCT, we don't deal with negative numbers. A score is between 0 and 1, so 0.001 is almost losing and 0.999 is almost winning for example. To change 0.99 to the other players point of view in this system, where scores must be between 0 and 1, you must negate it and add 1. So 0.99 becomes: 1 - 0.99 = 0.01 I hope that is what you are asking about and that this explains it. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
Hello, Yes, clearly MoGo is doing good stuff inside their playouts. I, too, would like to see if the result of a large-board MoGo playout looks any different from mine. Seems interesting! I'll do that (don't when though), hoping that MoGo's architecture would allow such big boards (not so sure yet :-)). Of course, it will only be using MoGo's simulation player, not MoGo itself, because games would take ages! :-) Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Łukasz On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: The only real change is to link against the Boost libraries I installed using DarwinPorts. Here are the diffs: -CFLAGS += -Wall #-static #-Wno-long-long -Wextra -Wno-variadic-macros +CFLAGS += -Wall -I/opt/local/include -L/opt/local/lib It's a desktop and I don't see any options for power management. Maybe it's just a difference in processors? It's a two core chip but perhaps not as fast at single-threaded apps. Adding multithreading might help. - Brian On 2/21/07, Łukasz Lew [EMAIL PROTECTED] wrote: On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: [resending; apologies if you get this twice.] Hi, Hi Brian, This is my first post to the list, so I'll introduce myself: I'm a software developer and just getting started with playing Go. I read the article in the Economist and thought that the work on Monte-Carlo based Go programs sounds promising. I'm not interested in writing my own Go program but would like to experiment with improving existing programs. Have fun ;) I built and started libego on an iMac with a 2GHz Intel Core Duo. The initial benchmark reports these results: Performance: 10 playouts 1.84255 seconds 54.2727 kpps Black wins = 43983 White wins = 56017 P(black win) = 0.43983 Are these numbers to be expected? They are correct, except rather low performance. It should be rather about 80 kpps (kilo playouts per second) There are few possible reasons for this: - You are using a laptop with power management - You changed Makefile or some source files to make it compile on Mac? Best Regards, Łukasz Lew - Brian ___ 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 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] Library of Effective GO routines v 0.106
Hello, I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Here, from my experience, the following can matter a lot: - version of g++ (g++ 4.1 gave me +50% against g++ 4.0 on an opteron!) - version of the libc: even compiled with a modern compiler, a program running on a machine with an old version of the libc can be very significantly slower (-30% observed!). - exact version of the processor: today the frequency means nothing, nor the name of the processor. You have to check the exact numbers. And I also observed that even the small numbers as the stepping number, matters. MoGo runs faster on my P4 3.4 Ghz than on a 3 years newer P4 3.8 Ghz, which has also more cache. I ran test on other P4, and the slower had a different stepping, that's all (all are dell computers using same hardware). - Measure of time: if you take the CPU time, on multiprocessor machine, while using multithreading, sometimes the reported time is not what you expect (generaly reported for all the threads), so when you calculate the speed of playouts, you can have a 2x/4x factor. Hope that can help, Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
if cache is your limiting factor that is usually shared. Also, if you are using processors with hyperthreading, it is possible. Or if bus bandwidth is your limiting factor... but if it is exactly 2x slower that is indeed very odd. My money is on the fact that you have a bottleneck somewhere else and those processors were operating below capacity the whole time and that now that you added more, it is becoming more obvious. If for instance, you had the following situation: thread A creates a queue of tasks for the rest of the threads to do. If thread A isn't able to keep the queue full, then obviously more processors won't help. The only other though I have is that your compiler isn't writing code that allows for proper multithreading. Can you be more specific on which processors are giving you a hard time? - Nick On 2/22/07, Łukasz Lew [EMAIL PROTECTED] wrote: I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Łukasz On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: The only real change is to link against the Boost libraries I installed using DarwinPorts. Here are the diffs: -CFLAGS += -Wall #-static #-Wno-long-long -Wextra -Wno-variadic-macros +CFLAGS += -Wall -I/opt/local/include -L/opt/local/lib It's a desktop and I don't see any options for power management. Maybe it's just a difference in processors? It's a two core chip but perhaps not as fast at single-threaded apps. Adding multithreading might help. - Brian On 2/21/07, Łukasz Lew [EMAIL PROTECTED] wrote: On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: [resending; apologies if you get this twice.] Hi, Hi Brian, This is my first post to the list, so I'll introduce myself: I'm a software developer and just getting started with playing Go. I read the article in the Economist and thought that the work on Monte-Carlo based Go programs sounds promising. I'm not interested in writing my own Go program but would like to experiment with improving existing programs. Have fun ;) I built and started libego on an iMac with a 2GHz Intel Core Duo. The initial benchmark reports these results: Performance: 10 playouts 1.84255 seconds 54.2727 kpps Black wins = 43983 White wins = 56017 P(black win) = 0.43983 Are these numbers to be expected? They are correct, except rather low performance. It should be rather about 80 kpps (kilo playouts per second) There are few possible reasons for this: - You are using a laptop with power management - You changed Makefile or some source files to make it compile on Mac? Best Regards, Łukasz Lew - Brian ___ 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 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 mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
The other thought (kind of silly) but just a pssing thought is that the threads that are benchmarking are keeping a local copy of their count and writing it back at the end (which is allowed) so you are actually getting good performance, but you don't know it because the processors aren't talking to each other properly. Exactly 2x is hard to imagine happening by chance. On 2/22/07, Sylvain Gelly [EMAIL PROTECTED] wrote: Hello, I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Here, from my experience, the following can matter a lot: - version of g++ (g++ 4.1 gave me +50% against g++ 4.0 on an opteron!) - version of the libc: even compiled with a modern compiler, a program running on a machine with an old version of the libc can be very significantly slower (-30% observed!). - exact version of the processor: today the frequency means nothing, nor the name of the processor. You have to check the exact numbers. And I also observed that even the small numbers as the stepping number, matters. MoGo runs faster on my P4 3.4 Ghz than on a 3 years newer P4 3.8 Ghz, which has also more cache. I ran test on other P4, and the slower had a different stepping, that's all (all are dell computers using same hardware). - Measure of time: if you take the CPU time, on multiprocessor machine, while using multithreading, sometimes the reported time is not what you expect (generaly reported for all the threads), so when you calculate the speed of playouts, you can have a 2x/4x factor. Hope that can help, Sylvain ___ 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] Big board. Torus ?
Quoting Tapani Raiko [EMAIL PROTECTED]: In 3D Go, you need a surface of stones to surround space but just a string of stones peeking in to ruin it. In normal 2D Go, you surround area by strings and ruin area by strings, so there is a nice balance. My guess is that Go in any other dimensionality than two would be dull. Playing on the surface of a ball, a torus, or a Klein bottle might be fun, though. I once played 4-D go 4x4x4x4 with myself which is of course very hard to visualize. But igonring that, the pfundamental roblem is that it is impossible to make eyes when attacks on the eyes has so many directions to escape. Every reasonable well played game will end in seki. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Algorithm helps computers beat human Go players
http://today.reuters.com/news/articlenews.aspx?type=technologyNewsstoryid=2007-02-21T181324Z_01_L20533484_RTRUKOC_0_US-SCIENCE-GO.xmlsrc=nl_ustechnology --- vice-chair http://ocjug.org/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Heikki Levanto wrote: On Wed, Feb 21, 2007 at 07:55:15PM -0600, Matt Gokey wrote: Whether it is a torus or not is irrelevant. The only thing that matters from a go game play perspective is the graph topology. If all points have 4 neighbors the actual physical shape or layout doesn't matter. There can still be subtle differences. In a standard torus, a ladder comes back to its starting point. If you twist the torus enough, it will miss, and fill the whole board... Hardly relevant to random players that don't understand ladders, but anyway... I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, or any other shape is completely irrelevant with regard to game play. The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is equivalent and therefore optimal. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, or any other shape is completely irrelevant with regard to game play. The only thing that matters is the graph topology. it is true that the only thing that matters is graph topology. it is also true that graph topology cannot be separated from the actual topology of the surface. dimensionality of the embedding space is irrelevant -- topology of the embedded surface is quite important. you should be able to extract the topology of the graph from any embedded surface upon which it can be drawn and vice-versa. s. 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
Sylvain Gelly wrote: Thank you all for your precise answers! Sylvain p.s. the find out more link at the bottom of your page http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games is pointing to the wrong place, isn't it? What do you mean? You mean you can't access the page, or the content is not informative, non relevant, not interesting? This is the text: The Mogo program was developed during Yizao Wang’s (a student from the Ecole Polytechnique, winner of the research centre’s prize attributed to the best intern for his work on Mogo) internship with collaboration from the TAO project-team (INRIA) and the CMAP (Ecole Polytechnique). The work was jointly conducted by Yizao Wang and Sylvain Gelly, a PhD student from the TAO project. Olivier Teytaud (INRIA), Rémi Munos (INRIA) and Pierre-Arnaud Coquelin, PhD student at CMAP supervised the project. Rémi Coulom (INRIA) provided development support and raised awareness of many of the ideas behind MoGo's success. find out more But, when I click on the find out more link, it takes me to http://cgos.boardspace.net/ !! Surely that is not what you intended. -- Rich ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
If I take a plane, I can draw a 9x9 board on it or a 19x19 board on it. I can also draw the previously mentioned circular / cylindrical board on it. Could you explain how you propose to extract the topology of these, given only the fact that I have drawn them on a plane? excellent point. :) i overstated my point quite a bit. let me be more specific and more careful and say that if you draw a grid that completely covers the surface of, say, a torus, where every crossing point in the mesh represents a point on the board, you cannot hope to do so in a way that makes the board act like a board drawn with those same restrictions on, say, the surface of a sphere. there is torus-ness embedded in your game board that you can't remove. the same goes for a covering mesh on a projective plane, a sphere with two handles and one cusp, etc.. the topology of the surface is important. on the other hand, the full graph description of a board as a (V,E) set is all that is required to define a game board. in the other direction, there are (V,E) sets that can't be drawn such that the only intersections drawn are those that are board points while keeping the drawing on any one topological object. these will have to be drawn on a different topological object to have this property. i'll answer your objection by noting that if you draw the board as a covering mesh, you can definitely tell whether or not it was drawn on a cylinder or a torus or a sphere. s. Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] UCT article
What do you mean? You mean you can't access the page, or the content is not informative, non relevant, not interesting? This is the text: (...) find out more But, when I click on the find out more link, it takes me to http://cgos.boardspace.net/ !! Surely that is not what you intended. Oh sorry, I misunderstood. Yes you are right :-). However this page is not mine, and I have no editing rights over it. Thank you for the report. I may report this error to the editor of this page. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see benchmarks, and find which benchmark is relevant to your program. Then, buy the processor with the highest value on this benchmark :-). Perhaps the most interesting question for me is: How will a Core2 (duo?) 2.33 GHz compare with my existing P4 3.2 GHz? In any case I guess I will have to retool the program to be multi-threaded to take advantage of the dual core. Should I also be worrying about converting to 64-bit? This one: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is 1.5 time the speed of my P4 3.4Ghz (already 1.2 faster than other P4 3.4Ghz). BTW, someone managed to overclock this processor to 5.182 Ghz !!! (http://www.hardware.fr/myocdb.com/processeur364.html). And 3.750 Ghz seems pretty easy to get (without very special cooling material, at a price of less than 30 euros). Hope that helps for your choice :-). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] scalability studies with UCT
I've been doing some interesting scalability studies with Lazarus. On the big 19x19 boards, along with the help of others, we tested versions of Lazarus against other versions of Lazarus at different levels. We set up individual versions of Lazarus where the weakest version was Lazarus doing 1024 play-outs and each subsequent version doubled the number of nodes examined. Each version would play the version above it and below it. The test was eventually discontinued, it was requiring an enormous amount of CPU time and the trend we saw was consistent. It was rare for one version to lose to the version just beneath it. There was some indication that at the higher levels tested the superiority was slightly diminishing, but we cannot say that with a lot of statistical confidence. It would require many months of CPU time to arrive at solid conclusions. I will give more detail in a future report and compile the data for you to see and draw your own conclusions. Meanwhile, I've also been doing some interesting scalability testing against GnuGo 3.7.9. The idea is to see how much difference each doubling in the number of play-outs makes in the result. I am testing with 5x5, 7x7, and 9x9 boards. The version of Lazarus I am using is UCT based with what Dave Hillis refers to as heavy play-outs, similar to what Mogo does with simple patterns and such. I think you will find the results interesting. I started with 5x5 boards. Since BOTH programs play close to perfection on 5x5 boards, the issue is what KOMI to set. The fairest komi proved to be 24.5 (my program does not deal with non-fractional komi.) With perfect play Black should win every point on the board even with 24.5 komi, but moving up to 25.5 is clearly silly as white would never lose even if he passes every time. So 24.5 is the best I can do. Here is a table showing what happened: Boardsize: 5x5 Komi: 24.5 Opponent: gg-3.7.9 K-nodes Score when Black Score when WhiteCombined score --- 1024 25/25 =100.00 0/25 = 0.00 25/50 = 50.00 0512 24/25 = 96.00 1/25 = 4.00 25/50 = 50.00 0256 21/25 = 84.00 1/25 = 4.00 22/50 = 44.00 0128 22/25 = 88.00 0/25 = 0.00 22/50 = 44.00 0064 22/25 = 88.00 0/25 = 0.00 22/50 = 44.00 0032 16/25 = 64.00 0/25 = 0.00 16/50 = 32.00 0016 17/25 = 68.00 0/25 = 0.00 17/50 = 34.00 0008 16/25 = 64.00 0/25 = 0.00 16/50 = 32.00 0004 16/25 = 64.00 3/25 = 12.00 19/50 = 38.00 0002 14/25 = 56.00 0/25 = 0.00 14/50 = 28.00 00013/25 = 12.00 0/25 = 0.00 3/50 = 6.00 I found it interesting that gnugo occasionally loses with WHITE as does Lazarus at most levels. From the table it can be seen that Lazarus tends to improve with black for each doubling. At 1 million play-outs it appears that Lazarus is playing close to perfect as it never lost a game. Of course only 25 games were played with each color. Clearly, 5x5 is too simple for such a test since there is such a strong bias for black to win. This is one test where it might make sense to try 25.0 komi and score draws. Now let's look at 7x7 boards. The 7x7 and 9x9 games are still in progress but here is the table of what I have so far in 7x7: Boardsize: 7x7 Komi: 8.5 Opponent: gg-3.7.9 K-nodes Score when Black Score when WhiteCombined score --- 1024 19/19 =100.00 17/20 = 85.00 36/39 = 92.31 0512 24/24 =100.00 17/25 = 68.00 41/49 = 83.67 0256 19/19 =100.00 8/19 = 42.11 27/38 = 71.05 0128 22/22 =100.00 7/22 = 31.82 29/44 = 65.91 0064 21/21 =100.00 5/21 = 23.81 26/42 = 61.90 0032 23/23 =100.00 4/24 = 16.67 27/47 = 57.45 0016 19/21 = 90.48 4/22 = 18.18 23/43 = 53.49 0008 15/24 = 62.50 10/25 = 40.00 25/49 = 51.02 00048/23 = 34.78 3/24 = 12.50 11/47 = 23.40 00024/17 = 23.53 2/18 = 11.11 6/35 = 17.14 00012/15 = 13.33 0/16 = 0.00 2/31 = 6.45 What is interesting about this test, is that the superiority of Lazarus over gg-3.7.9 at this board size is substantially greater than with the 5x5 games when I run an ELO rating analysis. Also, Lazarus NEVER lost a game as BLACK once doing at least 32,000 play-outs. Also, there appears to be a very heavy black bias using komi of 8.5. I don't know the correct komi for these games, but I heard somewhere that the correct komi is 9.0. Like the 5x5 test, since Lazarus doesn't know how to do fractional komi, I am forced to choose which side gets the raw end of the komi deal. However, it's still interesting to note that with the white stones Lazarus can still win 85% of the games against
Re: [computer-go] CPU for UTC
Thanks! That one CPU comparison is very helpful. So, indeed, there is a lot more to worry about these days than simple clock speed. Has anybody else done similar comparisons? :) P.S. I'll almost surely pass on overclocking, but I had heard rumors that current CPUs were running well under speed to reduce heat. Still, over 5 GHz is pretty impressive! -Richard Sylvain Gelly wrote: So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see benchmarks, and find which benchmark is relevant to your program. Then, buy the processor with the highest value on this benchmark :-). Perhaps the most interesting question for me is: How will a Core2 (duo?) 2.33 GHz compare with my existing P4 3.2 GHz? In any case I guess I will have to retool the program to be multi-threaded to take advantage of the dual core. Should I also be worrying about converting to 64-bit? This one: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is 1.5 time the speed of my P4 3.4Ghz (already 1.2 faster than other P4 3.4Ghz). BTW, someone managed to overclock this processor to 5.182 Ghz !!! (http://www.hardware.fr/myocdb.com/processeur364.html). And 3.750 Ghz seems pretty easy to get (without very special cooling material, at a price of less than 30 euros). Hope that helps for your choice :-). Sylvain ___ 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] Library of Effective GO routines v 0.106
Hi Richard, I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: I'm a little disappointed with the speed of a single threaded application on my core 2 duo system. I just bought a desktop e6700 processor and I run 64 bit linux on it.I originally wrote my UCT program on a 32 bit 2.4 GHz pentinum 4.Whether I SHOULD be disappointed or not I don't know - it's just that I had higher expectations based on all the hype. The ratio of performance I get is about 1.7. So it's as if I'm running on my old computer with the clock (and everything else) sped up 1.7 times. However, the core 2 in my machine is clocked faster than my old machine, so clock for clock I compute roughly 1.53 percent increase in performance for a core 2 duo. Obviously, those are rough numbers because each application can vary significantly based on many factors. I'm sure you know all about this but I'll enumerate them here anyway: 1. GCC is not yet optimized to handle core 2 duo (and that's what I use.) 2. The program was optimized on my old machine. I did stuff that made it faster on THAT machine. If I developed it from scratch on the new machine, it would probably be faster since I tend to profile, test, and optimize for what works on the machine I develop on. 3. core 2 duo is 64 bit and my program does nothing to take advanatage of any of this. 4. Of course it's pretty nice having 2 cores! 5. The core 2 is highly responsive to over-clocking but I have a cheap system. I doubt my motherboard and memory will support much overclocking and I haven't tried.Mabye I will someday. One thing I can say is that the system is very robust, it almost seems like I can run an unlimited number of things without it bogging down thanks to 2 processors and 2 Gigabytes of memory. The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't have to wait too long. FYI here is the compiler flags I use for gcc 4.1: CFLAGS= -Wall -O3 -march=nocona -pipe -fomit-frame-pointer -fno-strict-aliasing Some of those make very little difference. This is the output of cat /proc/cpuinfo for one of the processors: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2667.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 5325.28 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: - Don On Thu, 2007-02-22 at 07:51 -0800, Richard J. Lorentz wrote: The hardware portion of this topic is very important, at least to me since I'm in the market for a new laptop. :) The comment today the frequency means nothing is my main concern and I worry even more if I need to investigate all the other numbers associated with the CPU. I bet the laptop manufactures won't even be able to tell me things like the stepping number, anyway! So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? Assuming I go with Intel, will I get more simulations out of a Core2 machine than a Core machine, say, with the same clock speed? Perhaps the most interesting question for me is: How will a Core2 (duo?) 2.33 GHz compare with my existing P4 3.2 GHz? In any case I guess I will have to retool the program to be multi-threaded to take advantage of the dual core. Should I also be worrying about converting to 64-bit? Thanks!! -Richard Sylvain Gelly wrote: Hello, I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Here, from my experience, the following can matter a lot: - version of g++ (g++ 4.1 gave me +50% against g++ 4.0 on an opteron!) - version of the libc: even compiled with a modern compiler, a program running on a machine with an old version of the libc can be very significantly slower (-30% observed!). - exact version of the processor: today the frequency means nothing, nor the name of the processor. You have to check the exact numbers.
Re: [computer-go] Library of Effective GO routines v 0.106
On Thu, 2007-02-22 at 17:05 +0100, Sylvain Gelly wrote: So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see benchmarks, and find which benchmark is relevant to your program. Then, buy the processor with the highest value on this benchmark :-). Yes, if anyone wants to play I will temporarily open up my machine to you - giving you an account on my core 2 duo system. - Don Perhaps the most interesting question for me is: How will a Core2 (duo?) 2.33 GHz compare with my existing P4 3.2 GHz? In any case I guess I will have to retool the program to be multi-threaded to take advantage of the dual core. Should I also be worrying about converting to 64-bit? This one: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is 1.5 time the speed of my P4 3.4Ghz (already 1.2 faster than other P4 3.4Ghz). BTW, someone managed to overclock this processor to 5.182 Ghz !!! (http://www.hardware.fr/myocdb.com/processeur364.html). And 3.750 Ghz seems pretty easy to get (without very special cooling material, at a price of less than 30 euros). Hope that helps for your choice :-). Sylvain ___ 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] CPU for UTC
On Thu, 2007-02-22 at 09:02 -0800, Richard J. Lorentz wrote: model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is 1.5 time the speed of my P4 3.4Ghz (already 1.2 faster than other P4 3.4Ghz). Sylvain, You are getting much better than I am on the same hardware, because I'm comparing to a P4 2.4 GHz and only getting 1.7. Assuming the speed ratio is the same going from 2.4 to 3.4, then I'm getting much less than you.I would like to know why! Can you tell me which compiler, OS and compiler flag you are using for this? Also, why is your P4 3.4 already 1.2 faster than other P4 3.4 machines? - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
My Mac seems to have a relatively old version of gcc: $ g++ -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5367) c-24-6-157-150:~ skybrian But I just installed Xcode 2.4.1 which included a gcc upgrade, so apparently this is current on OS X. I'll have to figure out how to use Xcode and Shark. - Brian On 2/22/07, Łukasz Lew [EMAIL PROTECTED] wrote: I do not understand it. Maybe someone does? I've made some tests on 2 core processors, and I have strange results. Some of 2 core processors got results exactly 2x times worse than they should. Why? I have no idea. But 2.8 Ghz 2 core works exactly like my 1.4 laptop. Also version of g++ does matter. Łukasz On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: The only real change is to link against the Boost libraries I installed using DarwinPorts. Here are the diffs: -CFLAGS += -Wall #-static #-Wno-long-long -Wextra -Wno-variadic-macros +CFLAGS += -Wall -I/opt/local/include -L/opt/local/lib It's a desktop and I don't see any options for power management. Maybe it's just a difference in processors? It's a two core chip but perhaps not as fast at single-threaded apps. Adding multithreading might help. - Brian On 2/21/07, Łukasz Lew [EMAIL PROTECTED] wrote: On 2/21/07, Brian Slesinsky [EMAIL PROTECTED] wrote: [resending; apologies if you get this twice.] Hi, Hi Brian, This is my first post to the list, so I'll introduce myself: I'm a software developer and just getting started with playing Go. I read the article in the Economist and thought that the work on Monte-Carlo based Go programs sounds promising. I'm not interested in writing my own Go program but would like to experiment with improving existing programs. Have fun ;) I built and started libego on an iMac with a 2GHz Intel Core Duo. The initial benchmark reports these results: Performance: 10 playouts 1.84255 seconds 54.2727 kpps Black wins = 43983 White wins = 56017 P(black win) = 0.43983 Are these numbers to be expected? They are correct, except rather low performance. It should be rather about 80 kpps (kilo playouts per second) There are few possible reasons for this: - You are using a laptop with power management - You changed Makefile or some source files to make it compile on Mac? Best Regards, Łukasz Lew - Brian ___ 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 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 mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] documentation for the IGS protocol ?
Does anyone know of a document outlining the IGS protocol? There are a number of programs and servers which support the IGS protocol, including the IGS server. I am trying write a tool to interact with these servers and would prefer not to have to reverse engineer the protocol from the programs, especially since most implement only a very small handful of commands. I'm aware of http://panda-igs.joyjoy.net/java/gGo/igscp/IGSCP_draft.txt which is a set of extensions to the protocol, but which doesn't really discuss the protocol itself. The activities I'm interested in engaging with are: a) finding players worthy of watching b) watching their games c) playing games myself So I think I'm looking at most of the protocol. I'm currently not having much luck by trial and error, since at least one server locks out badly behaved clients... cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CPU for UTC
Assuming the speed ratio is the same going from 2.4 to 3.4, then I'm getting much less than you.I would like to know why! I agree. Can you tell me which compiler, OS and compiler flag you are using for this? See my other email. Also, why is your P4 3.4 already 1.2 faster than other P4 3.4 machines? I never knew exactly why, it is my machine at the lab, so I don't know exactly what is inside. The processor is: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.40GHz stepping: 9 cpu MHz : 3392.423 cache size : 512 KB And some experiments made me think that the stepping: 9 was the key difference from the other systems I tried. But maybe it comes from a faster RAM? Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CPU for UTC
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo :-) --- Richard J. Lorentz [EMAIL PROTECTED] escribió: Thanks! That one CPU comparison is very helpful. So, indeed, there is a lot more to worry about these days than simple clock speed. Has anybody else done similar comparisons? :) P.S. I'll almost surely pass on overclocking, but I had heard rumors that current CPUs were running well under speed to reduce heat. Still, over 5 GHz is pretty impressive! -Richard Sylvain Gelly wrote: So, what should I be looking for in a processor if I want to get the most out of my single threaded UCT program? The best way is to find a friend with exactly the processor you want and try your program on it... The second best is see benchmarks, and find which benchmark is relevant to your program. Then, buy the processor with the highest value on this benchmark :-). Perhaps the most interesting question for me is: How will a Core2 (duo?) 2.33 GHz compare with my existing P4 3.2 GHz? In any case I guess I will have to retool the program to be multi-threaded to take advantage of the dual core. Should I also be worrying about converting to 64-bit? This one: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping: 6 cpu MHz : 2660.110 cache size : 4096 KB is the fastest processor for MoGo I have access to. Each processor (there are 2), is 1.5 time the speed of my P4 3.4Ghz (already 1.2 faster than other P4 3.4Ghz). BTW, someone managed to overclock this processor to 5.182 Ghz !!! (http://www.hardware.fr/myocdb.com/processeur364.html). And 3.750 Ghz seems pretty easy to get (without very special cooling material, at a price of less than 30 euros). Hope that helps for your choice :-). Sylvain ___ 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/ __ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
Yes, clearly MoGo is doing good stuff inside their playouts. I, too, would like to see if the result of a large-board MoGo playout looks any different from mine. Hello, I did the experiments, but it seems that the results are not different from those with an uniform random player. Certainly there are so many uniform random moves before using any pattern that the result is not different. For those who are interested to look anyway (in 600x600): http://www.lri.fr/~gelly/mogoSimulationOnBigBoard.pbm ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote: I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: You seem to have exactly the same processor as I have access to. And I get much better performance than you. Maybe it comes from the system: - which compiler do you use? - which libc do you use? - what is your -march option and -O ? I use g++ 4.1.1, -march=opteron, -O3, and quite recent linux installation (Mandriva 2007). For me also, everything is in 32bits and I did not optimize further for this processor. Maybe changing these things would explain the difference between the performance I get and you get. (should be 2. for you). Sylvain I'm using gcc 4.1.2 on a new Edgy Eft Ubuntu distribution. My options are -O3 -march=nocona with other minor options that see to help a tiny bit. I'll try the opteron option to see what happens. I never tried that but I've tried other architectures and most of what I read claims the best to use is -march=nocona for the core 2 duo. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability studies with UCT
Le jeudi 22 février 2007 17:00, Don Dailey a écrit : It appears that at 9x9 Lazarus needs more play-outs to equalize with gnugo. However, it also appears that at higher levels the superiority is even greater than in the 7x7 games. This is non-intuitive and probably not really the case - I assume this is due to sampling error since fewer games have been played on this boardsize. We also need to see the highest level lose a few games as this surely distorts the table significantly (you cannot get an accurate ELO rating if you don't win AND lose some games.) I may try 11x11 or 13x13 boards at a later time - focusing on lower levels since the longer levels are very time consuming. I will post an update to this in a few days once I've gathered substantially more data. Thanks for sharing your experiments. btw, GNU Go have databases for joseki and fuseki on 9X9 and 13x13. Maybe running with --nojosekidb --nofusekidb otpions would be better for scale comparison. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9 for E6700) is very easy without core volt doping. -gg (Hideki) Don Dailey: [EMAIL PROTECTED]: On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote: I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: You seem to have exactly the same processor as I have access to. And I get much better performance than you. Maybe it comes from the system: - which compiler do you use? - which libc do you use? - what is your -march option and -O ? I use g++ 4.1.1, -march=opteron, -O3, and quite recent linux installation (Mandriva 2007). For me also, everything is in 32bits and I did not optimize further for this processor. Maybe changing these things would explain the difference between the performance I get and you get. (should be 2. for you). Sylvain I'm using gcc 4.1.2 on a new Edgy Eft Ubuntu distribution. My options are -O3 -march=nocona with other minor options that see to help a tiny bit. I'll try the opteron option to see what happens. I never tried that but I've tried other architectures and most of what I read claims the best to use is -march=nocona for the core 2 duo. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote: Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9 for E6700) is very easy without core volt doping. With 64 bits as your desktop, there are some issues with flash and java web start. I probably should have stayed with the 32 bit stuff, but I went ahead and installed the 64 bit version and will stay with this. I have heard that the 64 bit linux does run some things better. I suppose you could recompile things to work in 64 bit mode, and still run 32 bit OS, at least for the utilites that benefit from it (and there are some that do.)I haven't sorted it all out yet. - Don -gg (Hideki) Don Dailey: [EMAIL PROTECTED]: On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote: I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: You seem to have exactly the same processor as I have access to. And I get much better performance than you. Maybe it comes from the system: - which compiler do you use? - which libc do you use? - what is your -march option and -O ? I use g++ 4.1.1, -march=opteron, -O3, and quite recent linux installation (Mandriva 2007). For me also, everything is in 32bits and I did not optimize further for this processor. Maybe changing these things would explain the difference between the performance I get and you get. (should be 2. for you). Sylvain I'm using gcc 4.1.2 on a new Edgy Eft Ubuntu distribution. My options are -O3 -march=nocona with other minor options that see to help a tiny bit. I'll try the opteron option to see what happens. I never tried that but I've tried other architectures and most of what I read claims the best to use is -march=nocona for the core 2 duo. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] documentation for the IGS protocol ?
On Thu, 2007-02-22 at 17:50 +, Stuart A. Yeates wrote: Does anyone know of a document outlining the IGS protocol? There are a number of programs and servers which support the IGS protocol, including the IGS server. I am trying write a tool to interact with these servers and would prefer not to have to reverse engineer the protocol from the programs, especially since most implement only a very small handful of commands. This one looks reasonable complete and original (though a bit verbose): http://www.koders.com/noncode/fid2C78D24147B76E1CF1196C20428DC7BC62715F38.aspx Enjoy ;-) AvK ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: documentation for the IGS protocol ?
The NNGS clone on boardspace.net is still running, but completely idle. It would be a suitable place to test clients. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability studies with UCT
On Thu, 2007-02-22 at 18:31 +, alain Baeckeroot wrote: Le jeudi 22 février 2007 17:00, Don Dailey a écrit : It appears that at 9x9 Lazarus needs more play-outs to equalize with gnugo. However, it also appears that at higher levels the superiority is even greater than in the 7x7 games. This is non-intuitive and probably not really the case - I assume this is due to sampling error since fewer games have been played on this boardsize. We also need to see the highest level lose a few games as this surely distorts the table significantly (you cannot get an accurate ELO rating if you don't win AND lose some games.) I may try 11x11 or 13x13 boards at a later time - focusing on lower levels since the longer levels are very time consuming. I will post an update to this in a few days once I've gathered substantially more data. Thanks for sharing your experiments. btw, GNU Go have databases for joseki and fuseki on 9X9 and 13x13. Maybe running with --nojosekidb --nofusekidb otpions would be better for scale comparison. Oh now you tell me!!! Will gnugo play deterministically without the joseki? It's probably ok in either case - since Lazarus is MC it provides plenty of variety but I think I prefer seeing gnugo vary a little. By the way, I'm running everything at the default with GNU Go for this test. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CPU for UTC
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo Yes, I'd love to! Can you fund me? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
Hello, 2007/2/22, Martin Møller Pedersen [EMAIL PROTECTED]: The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't have to wait too long. It is what I have heard for years, so some times ago I took the time to use intel compiler (which not straightforward for objects as hashtable which are not part of the standard stl), and it is not better. It was 5 months ago, g++ 4.0 against intel compiler of this time, on a P4 3.4 Ghz. Perhaps it is different for core 2 duo, because it is new, but I believe it will not last long, and g++ 4.1 is much better. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
Ok, so I will probably give it a chance if it's free. I'll let you know if anything interesting happens. I really prefer to stay with GCC but if there is a big difference I will use intel until GCC starts optimizing for core 2, assuming it's usable. I'm not sure when this will happen, it seems like I read that gcc 4.2 won't have core 2 specific optimizations, so it may be a long wait. I could be wrong about that however. - Don On Thu, 2007-02-22 at 23:12 +0100, Sylvain Gelly wrote: Hello, 2007/2/22, Martin Møller Pedersen [EMAIL PROTECTED]: The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't have to wait too long. It is what I have heard for years, so some times ago I took the time to use intel compiler (which not straightforward for objects as hashtable which are not part of the standard stl), and it is not better. It was 5 months ago, g++ 4.0 against intel compiler of this time, on a P4 3.4 Ghz. Perhaps it is different for core 2 duo, because it is new, but I believe it will not last long, and g++ 4.1 is much better. Sylvain ___ 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] Library of Effective GO routines v 0.106
On 22/02/07, Sylvain Gelly [EMAIL PROTECTED] wrote: Hello, 2007/2/22, Martin Møller Pedersen [EMAIL PROTECTED]: The intel compiler is much better I understand and you can get it for linux too, but I'm too cheap to do this. GCC will eventually improve for core 2 duo, hopefully I won't have to wait too long. Just for the record that the quote above was _not_ made by me. /Martin ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
The difference is small, and only the renormalizations that would show any real differences. Or you could create a chart that tracks board size and average chain size and see if there is any association between the two. Do you agree that that is also a sensible test, David? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
I will think about that, but I know that the renormalization trick is very sensitive. I find it hard to believe that any other test could be any more sensitive. And I know the basis for the renormalization. One question for both of you: Are these the result of one random playout or are they from one MC player playing against another (each using many playouts to determine its move)? Cheers, David On 22, Feb 2007, at 2:51 PM, Chris Fant wrote: The difference is small, and only the renormalizations that would show any real differences. Or you could create a chart that tracks board size and average chain size and see if there is any association between the two. Do you agree that that is also a sensible test, David? ___ 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] CPU for UTC
Perhaps someone wants to implement MC algoritm in a small processor and create am array of PICs or something running MC. :-P (some really cheap PICs runs up to 200mhz these days...) or those programmables chips GPUs? I don't remember the name. MPMC = Massive Parallel Monte Carlo Yes, I'd love to! Can you fund me? On second thought, I don't think there's any way you can compete with modern CPUs in terms of bang-for-the-buck. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board
Are these the result of one random playout or are they from one MC player playing against another (each using many playouts to determine its move)? One MC playout. At 100 playouts per move, generating a 1000x1000 graphic would take something like 95 years to compute, assuming you did not upgrade your hardware during the computation. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
alain Baeckeroot wrote: Le jeudi 22 février 2007 14:11, Matt Gokey a écrit : The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is equivalent and therefore optimal. Yes. But the round board at http://www.youdzone.com/go.html is not isotropic, it is a cylinder. You can build it with a square garden wire netting cut at 45°, and add one wire on each border to have 4 neighbors everywhere. If you start from any point and go straight you end on a border. If you start from a border and go straight you stay on the border. I don't understand. I think everyone is thinking too visually. What does straight mean in the context of go? Only liberties are meaningful. It is isotropic if you stop visualizing the shape and only consider the graph. Here is a thought experiment to test: define the board only logically using a graph (nodes and neighbor nodes). No topological shape and no mesh layout over any shape is needed. If all nodes have exactly four neighbors, there is no method or algorithm that you can run to find an edge. All nodes will look equivalent. If it were a cylinder, there would still be a top and bottom edge indicated by nodes with fewer neighbors. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Library of Effective GO routines v 0.106
Hello Don, Thank you for the advises but I run 32 bit Fedore Core 5 on [EMAIL PROTECTED] Don Dailey: [EMAIL PROTECTED]: On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote: Hello Sylvain and Don, I prefer 32-bit OS as Core series is not better for 64 bit and try not nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9 for E6700) is very easy without core volt doping. With 64 bits as your desktop, there are some issues with flash and java web start. I know, thanks. I probably should have stayed with the 32 bit stuff, but I went ahead and installed the 64 bit version and will stay with this. Probably already you know but you could create a new partition, install 32 bit linux on it, and share /home etc. on one box with multi-boot. I have heard that the 64 bit linux does run some things better. I suppose Sure, Debian runs faster upto 20%, for example. It's mainly because, however, 64 bit linux is optimized for recent cpus while 32 bit linux is compiled partly for old i686 (kernel) or oldest i386 (other stuff). So, if you want to get the same performance on 32 bit, recompile all stuff for your cpu (ex. with -march=pentium-m for Intel Core). #This option will be changed for upcoming GCC 4.2. Pros of 64 bit: 1. Double the number of general registers (8 to 16). 2. Wide addressing area (over 4 GB). Cons of 64 bit: 1. Pointers are 8 byte long so that the effective cache size decreases. 2. Instructions are long and complex so that the decoding speed decreases. #AMD's are relatively better than Intel's on this issue. As a conclusion, if your functions/procedures are relatively simple/short and/or using pointers lot, 32 bit is better than 64 bit. -gg you could recompile things to work in 64 bit mode, and still run 32 bit OS, at least for the utilites that benefit from it (and there are some that do.)I haven't sorted it all out yet. - Don -gg (Hideki) Don Dailey: [EMAIL PROTECTED]: On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote: I'm very much interested in core 2 duo performance and would appreciate hearing what others have experienced in this regard. I don't know what OS you use, but here are my experiences so far with Linux: You seem to have exactly the same processor as I have access to. And I get much better performance than you. Maybe it comes from the system: - which compiler do you use? - which libc do you use? - what is your -march option and -O ? I use g++ 4.1.1, -march=opteron, -O3, and quite recent linux installation (Mandriva 2007). For me also, everything is in 32bits and I did not optimize further for this processor. Maybe changing these things would explain the difference between the performance I get and you get. (should be 2. for you). Sylvain I'm using gcc 4.1.2 on a new Edgy Eft Ubuntu distribution. My options are -O3 -march=nocona with other minor options that see to help a tiny bit. I'll try the opteron option to see what happens. I never tried that but I've tried other architectures and most of what I read claims the best to use is -march=nocona for the core 2 duo. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
I don't understand. I think everyone is thinking too visually. What does straight mean in the context of go? Only liberties are meaningful. It is isotropic if you stop visualizing the shape and only consider the graph. I think straight would mean that when moving from one node to an adjacent one, you make the move that maximizes the distance from your origin. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Le vendredi 23 février 2007 01:19, Matt Gokey a écrit : Here is a thought experiment to test: define the board only logically using a graph (nodes and neighbor nodes). No topological shape and no mesh layout over any shape is needed. If all nodes have exactly four neighbors, there is no method or algorithm that you can run to find an edge. All nodes will look equivalent. I was partly wrong, but i maintain this board is anisotropic : It contains squares and triangles, not equally spaced, all triangles are on the borders. Here is a simple algorithm to define the borders: Starting from one node and moving to the next, you can go to the Left, Front, Right or Back. - Insides nodes : if you go always to the Right, in 4 steps you are back to the initial position. - Near border nodes: there is one starting direction where you need only 3 steps to go back if you always turn to the Right - Border nodes: 9 steps. QED number of neighbors is not enought to define the topology, (i suspect this is well known ;-) So i maintain it is a cylinder, with 2 borders which correspond to our visual feeling. Alain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CPU for UTC
Check out: www.intel.com/go/teraflops Cheers, David On 22, Feb 2007, at 6:10 PM, William Harold Newman wrote: Some serious people are arguing http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html that, among other things, the sweet spot for performance is down around there, and perhaps presently we will get hypermodern CPUs (or, likely, chips populated by highly integrated CPUs, RAM, and network controllers as far as the I can C) which get their bang for the buck that way. There seem still to be a few open design issues, though.:-| ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Tapani Raiko wrote: Matt Gokey wrote: I'm not sure I agree with this. I hypothesize that 2d, 3d, 4d, torus, or any other shape is completely irrelevant with regard to game play. The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is equivalent and therefore optimal. It is true that the graph topology is the thing that matters, but having an identical number of neighbors for all nodes does not mean that the graphs are similar (isomorphic). For instance in the 3D diamond graph, each node (disregarding the edges) has 4 neighbors as usual, but there are 12 neighbor's neighbors, whereas normal Go board has only 8 (4 diagonals and 4 one-point jumps). I'd say there is a huge difference. OK, I see. That is of course a big and very significant difference. -So the graph topology is crucial not really the shape. -And if a board is empty and balanced with equal numbers of neighbors and uniform (e.g. same connectivity properties throughout) then any 1st play should be equivalent and therefore optimal. Right? A toroid board (defined as a normal square board with the top-bottom and left-right edges connected) would fit this condition, however, the round board does not appear to. Therefore they can't be isomorphic or structurally identical. When describing boards as mapped onto different shapes it would be helpful to describe the graph connectivity properties being imagined since so many different boards can be constructed on the same geometries. As for Don's original question about the toroid board, I think it does change the game significantly since it will be harder to make territory without edges and perhaps less interesting, but the first play is easy since any move is optimal and would not require running even one simulation ;-) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Nick Apperson wrote: I considered making a version of go that plays with tetrahedral geometry. It is a 3D arrangment where all nodes have 4 neighbors and the angles between each are 109 degrees. Its connection properties though are very different because of the way it it layed out. Hence, I am going to have to disagree. Now I understand what you were saying here. But if what you mean is that all that matters is the graph representation of the go board, I will agree with you there. Well that _is_ really what I meant, I just wasn't thinking of all other possibilities and implications. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board. Torus ?
Matt Gokey wrote: alain Baeckeroot wrote: Le jeudi 22 février 2007 14:11, Matt Gokey a écrit : The only thing that matters is the graph topology. A corollary is that on any board that is completely balanced at the beginning with identical number of neighbors for all nodes, any 1st play is equivalent and therefore optimal. Yes. But the round board at http://www.youdzone.com/go.html is not isotropic, it is a cylinder. You can build it with a square garden wire netting cut at 45°, and add one wire on each border to have 4 neighbors everywhere. If you start from any point and go straight you end on a border. If you start from a border and go straight you stay on the border. I don't understand. I think everyone is thinking too visually. What does straight mean in the context of go? Only liberties are meaningful. It is isotropic if you stop visualizing the shape and only consider the graph. You are right it is not isotropic - sorry - I didn't look at it closely enough. Here is a thought experiment to test: define the board only logically using a graph (nodes and neighbor nodes). No topological shape and no mesh layout over any shape is needed. If all nodes have exactly four neighbors, there is no method or algorithm that you can run to find an edge. All nodes will look equivalent. I was assuming the board was uniform or isotropic I guess when I wrote this. Mea culpa. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board, ++physics
Le jeudi 22 février 2007 01:16, David Doshay a écrit : It is pretty clear to me that, if the analogy to MC simulations in magnets is of any value, the temperature of the Go game you show is hotter than optimal. If the temperature were at the transition temperature, then each of the renormalized lattices would look just like a piece that size cut from the original. Because the details all get smaller, the original lattice is on the random, or hotter, side of the transition. Thank you very much for this work. I am mulling this over ... how to cool the Go simulation slightly from the pure MC that you did. Your analogy with physics encourage me to share other physical analogies. 1/ Cooling the simulation could be done by controlling the mixing rate and the density of stones. -Beginners'games are too cold, not enought mixed (=overconcentrated or very high viscosity, nearly solid state, not ignitable) -Professionnal games are probably near critical state (explosive conditions, gaz state) -MC-players are nearly random = too hot, too mixed, plasma state. 2/ Soap Bubbles = potential territory In addition to previous fluid state, i see hypothetical bubbles: - beginners makes some (less than 10) big bubbles, and their size and place are early known. (still too cold and too high viscosity) - professional can makes lots of bubbles (20+), but they are changing and turning very often and quickly - nearly-random makes a foam 3/ Solidification and cristal growth often comes to mind. Cristal growth need a seed to begin, generally it is a defect or some impurity. In go the defect are the corners: - they need less material to build a frontier (like soap bubbles) so corners are the beginning of the process of solidification or cristal growth. - the topology of the corner (2 libs, 3 libs and 4 libs) imposes the size and shape of a living group. - impurity is a captured stone/group 4/ shape/size resonance (un)fortunately the 19x19 size is just the critical size to have problems. -17x17 is too small, corners influence is too strong, it is quickly possible to take the border. (= 3 bubbles) -21x21 is too wide, it is not possible to quickly prevent easy invasion. (= 4 bubbles) (a strong go player told me: both are boring to play) -19x19 is critical, just in between, that's why it's fun (=3.1415 bubbles ;) I made very slow progress to formalize this, except density which is rather trivial, and a kind of temperature, but it needs a lot of go knowledge to work (something like gnugo internals), so it is not (yet) very suitable for a fast MC simulator. But the whole stuff is rather coherent in my mind. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Big board, ++physics
At 09:03 PM 2/22/2007, you wrote: 4/ shape/size resonance (un)fortunately the 19x19 size is just the critical size to have problems. -17x17 is too small, corners influence is too strong, it is quickly possible to take the border. (= 3 bubbles) -21x21 is too wide, it is not possible to quickly prevent easy invasion. (= 4 bubbles) (a strong go player told me: both are boring to play) -19x19 is critical, just in between, that's why it's fun (=3.1415 bubbles ;) don't know about bubbles, but i am under the impression that at 17x17, there corner and side territory is too large and the reverse is true at 21x21. at 19x19, there is a little less turf in in center. it's also hard to see why 21x21 would be boring (i can see 17x17 being too simple in some sense). thanks --- vice-chair http://ocjug.org/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
