[computer-go] Monte Carlo combined with minimax search

[Don Dailey]

Hi Chrilly,

I don't want to start a language flame war,  but I have done some
programming in Java,  and really do not like it at all.    After doing
some Java programming I started wondering why I wasn't doing it in C, I
could not see much difference except that you were more restricted in
Java.     

I know several high level languages and I tend to either want a high
level language or C,  Java seems to be neither,  much like writing in C
but without the flexibility and performance.  

I know that many people LOVE it, but I have found that many people love
every computer language there is.    Once you get really familiar with a
language you tend to like it.    I never got really comfortable with
Java and maybe that's why I don't like it?

But I am very comfortable with C and I don't like it either.   I use it
because there is nothing better for performance programming other than
assembly.  And you can get down to then nitty gritty of exactly how
things are stored - most languages "protect" you from that.

But when I really want a high level language,  I have gravitated to the
perl/ruby/python style of languages.   They are slow, but I use C if
speed matters.  

I have also discovered what I consider an under-rated language, tcl.  At
first it seems verbose to me, but I discovered that I was writing a
small amount of code to do pretty cool things and so  it is far more
expressive than I thought.  It's very "pure" in it's simplicity.    I
made the 9x9 Go server in a day and just a few lines of code in tcl.   I
got started with tcl for some business programming I'm doing - needed to
be cross-platform and I found it painless in tcl - GUI and all.   There
is a tcl package that let's you mix in C code very painlessly,  and so
it's possible to write programs that are fast.   I made a package that
has my GO program inside it without much thought.   I did this with the
intent of building a really nice user interface.   Other languages now
have similar C writing packages or modules to make it easy to write a
fast routine in C that looks like part of the language - so this is
nothing special but it's still cool. 

But my favorite "fun" language is Ruby.   If it doesn't need to be fast,
you can hack out something very quickly.   A lot of my GO tools, such as
my autotester is a ruby script.   I played with Python too and it's very
similar to ruby, more similar than different.   These are 2 great
languages.  

For the most part I like all languages,  it's great fun to play with and
learn a new one.   But I didn't like Java.   Java is one that I really
tried hard to like.

However, I think Java is a reasonable choice for complex projects and I
do not deny that it has it's good points.   Is there some inherent
problem with memory management with Java or do all garbage collected
languages suffer like java does from memory handling issues?   

- Don


On Mon, 2006-07-24 at 08:00 +0200, Chrilly wrote:
> I have ported a C chess programm which was initially written for a Hitachi 
> microcontroller to Java. The Java version was on a PC only 15% slower. One 
> can write C-programs in Java with the rules below. The 15% difference are 
> due to the better optimization of a C-Compiler. The Java to Virtual-Machine 
> compiler produces very poor code. Obviously the Just-In-Time compiler in the 
> runtime does only some loophole optimizations which can not compete with the 
> optimizations of a C-Compiler. When switching off the JIT-Compiler the Java 
> code runs 15 times slower.
> 
> The rules to produce very fast Java codes are:
> 
> a) Avoid new, any creation of new objects.
> b) Function/method codes are in Java expensive, because the correct method 
> is determined dynamically. I C its a simply "call" instruction. The standard 
> Java calling convention is by orders more expensive than in C. To circumvent 
> this problem one has to declare the class as final. In this case the 
> compiler can generate also a "call" instruction like in C. In my program 
> there was only one big final class which contained all the functions/methods 
> of the original code. I removed effectivly the object-system and wrote a 
> flat-collection of functions like in plain C.
> c) The Java Virtual Engine can only process 32-Bit numbers. All other data 
> are second class citizens which are converted to 32-Bit. Using e.g. a Byte 
> array makes things worse, because there is an additional Convert to 32-Bit 
> instruction involved. In case of the chess programm, everything was packed 
> as much as possible, because the Hitachi had only 4KByte of RAM. I had to 
> blow up things to ints or used the trick described in d).
> d) Do NOT convert C-structs to Java classes. The C-original used  a lot of 4 
> Byte structures with 4  1-Byte Elements. E.g a move is encode as struct { 
> Uint8 from, Uint8 to, Uint8 flags, Sint8 val; }
> I converted this to a 32-Bit integer and exctracted the fields with 
> bit-fiddling. This is much faster and compact than converting the struct to 
> a class. But it produces ugly and error-prone code.
> One could also use 4 int arrays. But the conversion was closer to the 
> original. Additionally is the 32-Bit fiddling method more cache-friendly.
> 
> I did this as a programming excercise, but I see no point of writing bad C 
> Code in Java.
> 
> Chrilly 
> 
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/