don, i agree, although i will point out one of C's biggest flaws, which happens (conveniently for the sake of this argument) to be its least important one for game programming:
string handling sucks if i never have to handle a string, i'll choose C without question. when i need to handle strings, i choose C with major reservations. s. On Thu, Nov 27, 2008 at 11:55 AM, Don Dailey <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > _______________________________________________ > 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/
