Yes, I agree with all your points. FFTW works by building test cases and testing them on the specific processor it runs on. In other words, under program control, many versions are produced just to see which one actually runs fastest. I know the inventer of FFTW (Mateo Frigo of MIT) who also contributed a little bit to my chess program. The code is produced in scheme or lisp but it's produced FOR C. This may not be the case any more, I haven't kept up with FFTW, but I can imagine the same concept being applied with other languages.
Mateo was interested in my move generator for chess. It was super fast because I was able to eliminate most of the branching and it was based on code that produced code which caught his interest. Although I didn't use Mateo's technology, we talked about it. It's my dream that something much better will replace C and I'm hopeful that this day will come. I think it will be something like C but much better. I call it a better C, but that doesn't mean it has to look like C, I just hope that it replaces C. To replace C it has to be more than just fast like C, it has to give you pretty much complete control over your code. It's more fun and productive (in the code writing sense) to program in a much higher level language but there are conflicting goals. It's hard to be both a high level and low level language. A true successor to C will probably still be a relatively low level language. My bet is currently on D, but it's too early to be able to predict. - Don Harald Korneliussen wrote: > 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/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
