Re: what is the best language for go:Re: [computer-go] Score estimating

[Don Dailey <drd@xxxxxxx>]

I want to  address your comments about how fast  gnugo plays and using
high level languages.

I played  a couple games of gnugo  vs gnugo (using gtp)  and each game
last approximately 20 minutes on my 2.4 GHZ standard no-name PC.

I did  all the  math and on  average a  move takes about  4-5 seconds.
That's pretty fast,  but if the same code was written  in Python, I am
guessing that it would take AT least 10X longer, maybe much more.  (We
should try to  run John Tromps Fhourstones benchmark  on it.  Mabye we
can talk John into coding it up in Ruby?)

Now we are talking about taking a minute or more.  

But gnugo  probably plays slower than  it ever has (give  or take some
versions that  addressed inefficiencies), since  it tends to  get more
sophisticated  as the  years go  by and  computers get  faster.  Other
programmers on this  group have admitted that there  programs do a lot
more now than many years ago since more power is available.

My point  is that  GNUGO is fast  only because  it's written in  a low
level language.  There is a  big tradeoff because even though you have
more power of expression and fewer  bugs in a high level language, you
have  a compensating  factor, a  slow program!   Ultimately that  is a
limit too.

Years ago,  when I programmed chess  in assembler, I  was surprised at
how fast you could code.  I had read all the stuff about how you would
be 10X  slower writing  code and  it just wasn't  true.  In  fact, the
actual coding time isn't that  much different, it's the debugging time
that gets you.   But after a while  you get good at this  too and it's
not so bad.

You develop defenses to this.   Dave Fotland says he avoids malloc and
it turns  out that I  never use malloc  either unless there is  a very
clear need for  it, or just in very simple  contexts.  For instance at
the beginning of the program, you can use malloc to set the hash table
size if  you want it to be  an adjustable parameter.  It's  hard to go
wrong here.  When a program crashes, you usually know exactly where to
look and in the tougher cases  a debugger finds it quick.  If you test
little pieces as you go, it's a lot better.

High level  langauges are  very compelling and  I love them,  but they
have to go fast to be that compelling to me.

- Don




   > Be careful proposing lines of code as a software metric or someone 
   > will post a perl one-liner that does minimax search and therefore 
   > solves go ;-). 

   I am agree, if the clarity of code suffer, but from my own experience,
   if the clarity of code is the same, I prefer short code which fit
   better in my head. To keep on my example, I was always afraid
   to use introspection in java, because it is much longer.
   the number of line of code is another way to explain that

   I prefer to use

   for line in open("myFile.txt"):
	 print line

   than  use, something like:

   import java.io.*;
   public static void main () {
       InputStream file = FileInputStream(File("myFile.txt");
       String s;
       while( (s =file.readLine() ) !=null) {
	       System.out.println(s);            
       }
   }

   It is a lot more long, and clearly, there is some mistake
   on usually thing (file.readLine ???). Moreover, the added
   liens don't give us more clarity

   It's different to compare with one liner of perl
   which is
   print while(<>);
   By loosing variable names and special construct, Perl
   loose a lot of clarity.

   > For those considering scripting languages for quick development and 
   > algorithm evaluation might I suggest writing an extension to wrap 
   > gnugo's tactical search.

   That should be a good way, I am seriously just thinking about that.
   I don't believe that only one language can don't do everything.

   > You can't do much of anything without tactical information on chains, 
   > and tactical search needs fast code (e.g. as David Fotland said in 
   > this thread, Many Faces has carefully crafted C code for tactical 
   > search and the program still spends 70% of its time there).

   My main exeperience is playing with gnugo. I did not feel that time is
   a problem (he play very fast) It seems that the problem is  he plays 
   very strange
   things, as this strange shimari.

   | . . . . . . .
   | . . . . . . .
   | . . . + . X .
   | . . X . . . .
   | . . . . . . .
   | . . . . . . .
   |--------------- 


   My personal feeling is to explain how strange this shimari,
   a high level language is more usefull than carefully crafted code.
   It seems that gnugo first decide to play a san-san and then played
   a kind of shimari. How can he win if the value of the moves he play
   don't depend of the possible following moves

   In an other way, as I have really few experience in go programming,
   mabe you find my advices too far from the reality. But I really wonder
   that how the lack of startegic sense can be compensated with brute force.

   I hope I did not make too much noise with my suggestion of Python.
   But I am still convinced that as long as performance don't matter, the 
   higher
   the langage is, the best is too find new points of views. And seeing how
   fast gnugo play, I am not sure that performance really matter. He really 
   read
   well the semai but half of time it's not the importants ones.

   _______________________________________________
   computer-go mailing list
   computer-go@xxxxxxxxxxxxxxxxx
   http://www.computer-go.org/mailman/listinfo/computer-go/

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/