[computer-go] Language War!

[Dave Denholm]

Peter Drake <drake at lclark.edu> writes:

>> Have you considered GCJ? http://gcc.gnu.org/java/

> A possibility, although I'm concerned that GCJ only "supports most of
> the 1.4 libraries plus some 1.5 additions". We use generics,
> autoboxing, and enhanced for loops all over the place. (I know those
> last two are bad for speed, so we've largely expunged them from the
> core routines.)
>

But perhaps it is a smaller job to convert from java 1.5 to a flavour
of java that gcj understands. Since as you say, the latest java
features tend to be slow anyway.

I assume you've tried profiling the java execution. Is it an option to
write the critical parts as native methods ? JNI is a bit
unwieldy. The docs imply that gcj allows code to be written in a
mixture of java and c++ ? Never tried it myself.

> There may be some larger issues. For example, Anders Kierulf was in
> town recently and pointed out that in C++ it's possible to allocate
> objects on the stack rather than the heap, this avoiding the memory
> manager.
>

True. Though reusing objects will also avoid this problem.

One benefit of c++ is that you can use unions and arrays of
structures. java tends to end up with arrays of references to
structures allocated elsewhere, which is bad for locality of
memory accesses, and hence cache. And of course c++ doesn't insist on
doing all those array bounds checks...


> Speaking of memory management, since our main data structure (the
> enormous search tree) is acyclic, we can use reference counting...
>

Some say that it is better just to let the gc to all this for you. I'm
still undecided on this.

dd
-- 
Dave Denholm              <ddenholm at esmertec.com>       http://www.esmertec.com