[computer-go] Making Java much faster

[Chrilly]

>
> However, we are finding C++ an exceedingly frustrating language to  work 
> in. I won't go into the details here -- we don't need another  language 
> war -- but suffice it to say that it seems like we're  spending a lot of 
> time messing with details that aren't of interest  for the research. Now 
> that I've found that Java can have speed within  a factor of 2 of C++, I'm 
> thinking of going back to Java.
>
I have run over the years bug-statistics. At least in my code the error-rate 
is language independent. This holds even for Assembler and 
Hardware-Description languages.
There are some typical errors one makes in one language which are not done 
in another one. But overall this has minor influence one the bug-statistic. 
The "real" source of bugs are exceptional cases and not well understood 
concepts or a new concept which does not fit to the initial design. E.g. 
there is hardly any chess programm which has no enpassant bug.
C and Java are in my opinion almost the same languages. I think the error 
rate and nowadays also the speed is very close. Its just a matter of taste 
and not of any real advantage of one language.
Concerning memory leaks I think one should avoid to allocate memory at all. 
This makes the programm faster and avoids memory leaks. E.g. Suzie has 
besides allocating the hashtable at startup no memory allocation. I had also 
a mixture of UCT with an static evaluation and even this version had not 
memory allocation.
If one allocates dynamically memory, a memory leak is a sign of a flaw in 
the design. The Java garbagge collection avoids the crash. But this is no 
advantage, because the flaw is just hiden.  The programm will also "eat up" 
memory in Java. A bug which lets the programm crash is a harmless bug. The 
really bad bugs never show up.

Chrilly