Re: computer-go: Computer Go hardware

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

Hi Mark,

I think we have to be careful about how we assess progress.  Dave gave
an extremely optimistic report compared to  yours and I'm not inclined
to  trust either too much, not  because I don't  think anyone is being
honest,  but  because  these  things   absolutely  require  more  than
subjective  judgements and feelings.  It could  very well be true that
you are correct here.

The only trustworthy way to get an objective answer to my questions is
to run these   old programs on  their  old hardware  against  the best
programs today on the   best hardware.  It   makes no sense to run   a
couple of games  either, we would have  to see 20 or 30  just to get a
rough  idea, unless the  score was  really convincing  one way or  the
other.  Knowing how much time each  program spent is  good too, but we
also would like to know if the programs  in question (particularly the
old ones) care what  hardware they run on.  If  not, their strength is
completely bounded and hardware is not the limiting factor.



> This is also not to say that other programs don't use the computer power of
> todays hardware to get a little stronger. But I believe the same level can
> be achieved with a computer that runs 100 times slower. It just would take
> more effort to do so. The discussion here is how efficiently does the
> hardware get used by current Go programs and my opinion is that that
> efficiency is very, very low.  

I  think  you nailed it  exactly.  It's  just my  opinion, but when we
figure out   how  to really write Go   programs  correctly, they  will
automatically respond to all the computing power we  can give them.  I
feel this way  because I believe a "correct"  program will  be correct
precisely because it is efficient, it doesn't "waste" the hardware.  

I also don't believe there is a good reason to support the notion that
only software matters,  we are just at a  stage where there is so much
to be done in software that it's  by far the  biggest factor...  right
now.  It's kind of like we are using bubble sort instead of quicksort,
and instead of worrying  about getting a  faster computer we should be
changing our   sorting algorithm since   it  will  give  us much  more
performance than a faster computer will.   But once we have done this,
our next step would logically be to get a faster machine.


>                                 The results against a ten year old program
> provides some proof to this. This is not necessarily a criticism of Go
> programs because I think nowadays this is the case with almost all software.
> Hardware is cheap and programmers are scarce/expensive so there's a strong
> tendency to look for solutions that reduce the amount of programming time in
> return for using more computing power.

Yes, we do things we wouldn't have even dreamed about a few years ago.
I actually look back to what we managed on 4  MGz machines with 10 MEG
hard drives.  I  wrote software back then  that could  run a business,
and we  thought  we had  a    lot to work   with.    It's amazing  how
efficiently we could do things.  We cared about each and every byte!


> Although I love hardware to get faster with more memory all the time, there
> are days when I wish for it to stop. This in the hope that software makers
> would start spending time in fixing existing problems in their software and
> make it more efficient instead for the perpetual flight forwards into more
> bells and whistles. Go programs don't fall in that category of course, any
> means by which the program can get stronger should be used.

I think we have  been a little  victimized by this  too.  It's a  good
thing, but it is bad too.  It's like the  poor man who suddenly gets a
lot of money and throws  it away foolishly.   If the hardware progress
had  been much  slower, I'll   bet we would  know  more  about writing
efficent software.


Don