Don Dailey skrev:
On Tue, 2008-11-04 at 09:24 -0800, Zach Tellman wrote:
There are few languages other than these that offer reasonable
performance, not worse than 2X slower than C, but they tend
to be
memory hogs. Java is one of them. I cannot imagine every
seeing a top
chess program written in Java, or anything that is really
memory
intensive as good GO program tend to be. Is any of the
2200+ GO
programs on CGOS written in anything other than C?
To be fair, I did write an early version of Ergo in OCaml, and it was
equally fast and arguably quite a bit cleaner. I returned to C++
because an OCaml library would be useful to probably no one but
myself. So if you want to release something to the public, I agree
that C/C++ is the way to go. Other than that, I don't think that
computer go development has been extensive enough to argue that it's
spanned all possible approaches.
I agree. I was intentionally a bit provocative here as I want people
to comment on other languages that might qualify. I had completely
forgotten about OCaml and that might very well be a possibility too.
- Don
_______________________________________________
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/
It's good to be a bit provocative :) Speed of execution is but one of a
multitude of axes to consider. Expressiveness is another one. A more
concise representation should allow for faster turnaround and testing.
Reading, writing and grok time add up pretty fast unless the compiler
is slow as a dog. A decent type system to catch bugs. Latest Java has a
more decent than not type system. C/C++ type systems are best not
spoken about.
If one takes the position that bugs have a pretty significant impact on
the strength of a program (A position I agree with) one could be pretty
forgiving about the speed of execution of an algorithm if it is written
in an expressive language with a top of the line type system since it
delivers a double whammy to bugs. It actually doesn't seem like a bad
move to be half or third speed to the top of the line speed monster then.
Several other lines of reasoning might lead to different choices also.
Interactive development and testing and/or superior visualization
frameworks might lead to breakthroughs in pruning/exploration v.
exploitation ratios/patterns/generalization techniques.
/Dan Anderson
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
