[computer-go] Making Java much faster

[Don Dailey]

The thing about java is that it seems to be a big memory pig.
I can't have multiple java processes running without suddenly 
getting a lot of memory thrashing.  

If I do things in C,  everything screams.    I always figured
this is a problem with java that will be solved - but to this 
day it hasn't happened.   I still consider it basically broken,
or at least not usable unless you are treating your machine like
a single user, single process machine like the old days.

I don't have this problem with other high level scripting languages
so it cannot be blamed on dynamic memory allocation.

It has pretty much turned me off.

- Don


On Wed, 2006-11-29 at 09:37 -0800, Peter Drake wrote:
> On Nov 29, 2006, at 9:26 AM, Eduardo Sabbatella wrote:
> 
> > I'm a full time worker. Before starting my engine (a
> > couple of months ago) by 3rd or 4th try. I concluded
> > this:
> >
> > It will be impossible for me to do anything in C, C++
> > because I will have to focus on not having memory
> > leaks, range errors, etc.
> >
> > My engine nowadays is winning agains gnugo on lower
> > levels. Without time constrait. Ok, gnugo takes 10
> > secs to play, my engine 90 seconds.
> >
> > But, something I has sorted out in the beginning:
> >
> > - I have to optimise  algoritms, not code.
> 
> I agree absolutely, and have seen this advice in many books. One went  
> so far as to propose the two rules of optimization:
> 
> 1. Don't to it.
> 
> 2. (For advanced programmers only) Don't do it yet.
> 
> Algorithmic improvements are much more important than local  
> efficiency improvements.
> 
> > I think Drake follow the correct path, first optimise
> > algorithm on Java, then move it to C/C++.
> 
> Since computer Go algorithms are always, to some degree, in flux, I'm  
> now leaning toward staying in Java. Yes, C/C++ allows fine control,  
> but it also requires such fine control that it's hard to think about  
> larger algorithmic issues.
> 
> > Personally, I found that creating objects in Java is
> > realllly expensive. My engine use a lot arrays of
> > ints, longs, big linked arrays by reference numbers.
> > (yes, a'la C... sometimes I have to resize arrays, its
> > costy, but I found that its a lot cheaper on overall
> > perfomance than creating objects).
> 
> Yes, in both time and space. I intend to go to some lengths to avoid  
> dynamic object creation, e.g., creating all of the objects at startup  
> time and just clearing them out when I need "new" ones. For the most  
> memory-intensive part of the program (the enormous search tree), I  
> intend to use a big array of raw ints. Yes, this will be just as ugly  
> as doing it in C/C++, but at least I'll be able to confine the  
> ugliness to that part of the program.
> 
> Peter Drake
> Assistant Professor of Computer Science
> Lewis & Clark College
> http://www.lclark.edu/~drake/
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/