On Thu, 2008-11-27 at 16:22 -0200, Mark Boon wrote: > Don, > > I'm not going to argue about the merits of Java or C++ as it won't > change anyone's point of view anyway. > > What you're arguing is you should use C/C++, period. Fine by me if > that's what you think is best. > > But that's not what Denis was saying. He didn't specify he'd start > with C/C++, although that may be likely. He was saying he would move > to a more flexible language like Java later. That's the part that > doesn't make sense to me. Your litany against Java seems irrelevant > in this context.
I don't know what Denis meant, but it doesn't seem likely that he wanted to start with a low level language and then move up to a higher level language. That's what Dave Dyer thinks he meant and maybe he did mean that, but I'm inclined to believe we just didn't understand him. My "litany" wasn't supposed to be against Java. It was against what I consider to be a myth, the idea that it makes great sense to start with a high level language to figure out what you want, then recode it all from scratch in a high performance language. The use of C is almost the only choice, but I'm on the lookout for the next wave of languages that will be: 1. Native code compiled - no external runtime required. 2. High level language features, but not imposed on you. I think we are poised for this now. Lisaac seems promising, bitC, Digital Mars D, and Vala seems very interesting. I think there are couple of others mentioned here too. These all seem to be a step in the right direction to me, these are languages that can be used for very low level control without too many compromises. One of them could be the next C. We may look back in 10 or 20 years and see that we have been foolish. It could be that the problem is with the processors we use, designed a very specific way to basically support C programming. So maybe we are perpetuating our own nightmare. - Don > Mark > > On 27-nov-08, at 14:55, Don Dailey 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/
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/
