> However, perhaps there are ways to make testing a Go program use less clock 
> time? 

This is the right idea.   

Chess programmers use massive automated testing - playing games.   To
measure a small ELO improvement in your program requires tens of
thousands of games.    I think it's something like 100,000 to measure 1
or 2 ELO with high confidence.  

It might make sense to test your scalable go program at levels where a
game can be completed within 2 or 3 seconds.   In this way, if a changes
hurts your program significantly you can measure this within minutes.  
If it's a 5-10 ELO improvement you can measure it in a few hours if you
have a few computers.
 
At the level my program is at,  I would be happy just to measure 20 ELO
improvements so on the 3 CPU's I have I could do this relatively quickly
if I speed up the tests to a couple of seconds per game.

One must seek a compromise.   Ideally, you would prefer to test at
levels similar to what you will actually be playing.   But this is not
practical if you want high confidence in small improvements.

I know that most go programmers don't concern themselves with small
improvements because of the sense that there is bigger fish to fry.   
But this is wrong thinking.   If you can get 10 small improvements it
can be equivalent to one very large improvement.  

- Don




Brian Slesinsky wrote:
> Thought I'd emphasize this point:
>
> Don Dailey:
>   
>> I spend a great deal of time waiting on the computer,  because I have no 
>> clue what will work and I must test it.
>>     
>
> This makes Go programming somewhat unusual; for a lot of programs, you
> can arrange so that compiling and running your tests only takes a few
> seconds.  But if waiting for test results takes hours or days, the
> highest-performance language is also the the most productive one to
> develop in, because you can do more iterations in any given amount of
> time.
>
> However, perhaps there are ways to make testing a Go program use less
> clock time?  Could testing on smaller problems give results similar to
> testing on larger ones?  Or suppose tests could be run in parallel on
> something like Amazon EC2?
>
> - Brian
> _______________________________________________
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to