> I don't see the > logic why you > can't do in Java something that performance gurus do > in C. Just > because it's Java? Because it makes sense?
the garbage collector might make you a little bit more afraid of churning through objects, and the difference between a new() and a malloc() is significant. you can't really easily optimize around those things, although it's arguable that many times you don't need to call a deconstructor or free() until your code exits... i dunno. java is very cute and allows for really clever OO things, none of which are all that fast. i'm probably just a cro-magnon here, but i think that clever data structures (or even cleverer addressing) and tight code get you the same flexibility with much less overhead than being able to do it in a general way in arbitrary cases for the whole language. C -> assembly is a much smaller gap than Java -> C, and the bigger the gap, the more difficult the gap is to make up. i guess one way to test this whole line of reasoning is to have your program play itself -- giving one copy 30% less time. what's the win % in that case? or have one copy play a fixed opponent (say, gnugo) and have the other copy play that same opponent with 30% less time. then compare win %s. my guess is that the "X% more/less time" vs. "win %" curve is very steep at first in both directions, then levels off. has anyone tried anything like this? does it look exponential, or sigmoid-esque, or what? s. ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
