[computer-go] language choices

[steve uurtamo]

> 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