On Thu, 2008-11-27 at 13:03 -0200, Mark Boon wrote: > You say you're going to try to make a prototype first and then when it > shows promise, move to a more flexible language like Java. What > language are you intending to use? It seems the wrong way around to > me. Develop the prototype in a flexible language and when it seems to > work, move it to a specific langauge that can leverage some specific > CPU features. Seems to make much more sense to me.
This is clearly the conventional wisdom, but I think it's a mistake for an "ultimately" high performance game program, even for an initial prototype. The supposed benefit is "freedom to experiment" and nail down your algorithm, but I think this is a myth. I know that sounds like blasphemy, but when I've tried this before I discovered that even though C/C++ is pretty gnarly, it has at least 3 major advantages that might not matter for many other things, but is very important for games: 1. It's about as fast as you will get. 2. It is superbly flexible. 3. It is not a memory hog. To summarize my experiences, these wonderful high level languages are full of limitations and you spent more time pulling your hair out to work around them. Even the speed limitation is more of an issue that you think, if you make heavy use of testing. If you don't make heavy use of testing, you don't know what you are doing anyway. For instance, let's say you are experimenting with an algorithm. At some point you must test that algorithm to see if it's better than what you were doing, or to compare it with something else. You must play a large number of games to measure superiority, unless it is overwhelming. Most changes won't be overwhelming and even if it is you still need a lot of games to know how overwhelming it is. With a slower language this is correspondingly a slower process, negating much of the supposed high level language advantage. I spend more time waiting on tests than programming, even in C. Someone says, but if you have a large bank of workstations ... Well if you do, it doesn't change the fact that you are wasting them. An author for a strong playing engine for any game will be able to utilize as much power as you give him for testing. If I had 100 workstations I still would not use Ruby (a joy to program in and one of my favorites) because what a stupid waste of resources it would be to make those 100 workstations perform like only 2 or 3 workstations. When developing the simple reference bot, and experimenting with ideas to make it play better with fewer simulations, guess what? I am performance bound - I cannot test ideas fast enough and this would be worse with a high level language. A word about Java, which will probably produce some anger because I know some of us here love Java. I have never seen a top level, non-trivial game playing program in Java. I don't think you could build a strong chess program in Java. Probably more due to memory issues than performance - but I think for a top chess program performance would be an issue too. Yes, it's possible to write some programs in Java that are almost as fast as C, but probably not a chess program. You really need system level programming type of flexibility that C provides, not high level abstractions that the processor doesn't care about, and the compiler cannot optimize away. An ad-hoc poll: What is the strongest Java playing program on CGOS? I can't see building a very strong MCTS GO program in Java, because even in C, the tree does not fit in memory. My little reference bot can be done in Java however. The performance loss is modest and memory isn't an issue. But the code is clearly larger. Perhaps because I'm not a Java expert, it seems to take more code to do the same thing in Java. All kinds of scaffolding required to use the standard data structures. Much more typing. System.out.printf() is just one example. Seems like a little thing and I'm nitpicking - I see some value in this kind of anal-ism for big projects especially, but it's pretty annoying. I cannot see an ease of use difference between Java and C but I can imagine with large projects Java has some advantages. With it's strong typing Java seems almost as low level to me as C. To summarize, I have found over the years that just plain CPU/MEMORY performance is the primary barrier not just to program strength, but development time. You must measure development time 2 ways. One is how many man hours are spent, and the other how much "calendar" time is spent. With a high level language you can (in theory, but maybe not in practice) minimize man hour time, by giving up calendar time and dramatically increasing testing time (which need not involve the programmer.) But you also would have to be willing to wait much longer between tests and be willing to work piece-meal on a project while mostly waiting for tests. You will also inevitably take more shortcuts in testing because it takes so long. - 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/