Don Dailey wrote: >By the way, I am no fan of C. I don't like C and have tried some of >the languages on your list of languages that are supposedly faster than >C. > >I think you must be getting your information from the web pages for >those languages. As a general rule any reasonably fast language is >going to claim to be faster than C but shame on you if you believe it. > >"In theory" all languages are equal. They can all be transformed to >optimized machine code. I am not talking about the theoretical, I'm >talking about the reality. And the reality is that right now C is the >choice, whether I like it or not I accept it and hope something better >will come along.
You are right, but there are some cases where alternatives may make sense. For instance, look at the paper Ian Osgood linked to: They used Haskell to spit out highly optimized code for Monte Carlo-simulations. There is also FFTW, which makes very fast FFT code with the help of OCaml. Code generation is one area where using another language might be considered. It doesn't have to be a functional one, or even C: I know of a cryptographic algorithm (Serpent) that has an implementation based on Perl-generated Ada code. Prototyping may also be an idea. Especially if one is experimenting with novel approaches, wouldn't it make sense to make a prototype in Haskell, for instance? Then you may reimplement it in C, very carefully, comparing outputs regularly to check for the playing strength-killing bugs Chess programmers always talk about... Occasionally there may be some language feature that makes up for the performance cost. Like the distributed nature of Erlang, or the software transactional memory libraries that GHC Haskell come with. If you believe the hype, STM scales much better than locking-based shared memory. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
