Author: Robert Hyatt
Date: 10:01:55 11/14/02
Go up one level in this thread
On November 14, 2002 at 11:02:37, Vincent Diepeveen wrote: >On November 13, 2002 at 14:59:56, David Rasmussen wrote: > >I actually wrote a checkers program in Gofer (functional language >developed at university amsterdam). > >In fact it was international 10x10 checkers for a 8x8 board. It >searched about 1 node a second at a P100. > >That was not compiled. The gofer2c conversion tool they had was >very incompatible written for turbo-c, even by then completely outdated. > >Yet i tried that once too and it was about a factor 20 faster than runtime. > >I translated the code by hand to C and it was a factor 10000 faster. > >Of course some gofer experts were not happy when i posted that publicly >around. They rewrote my code. After some weeks fulltime work they managed >to speedup my gofer code a factor 2. > >Only left a factor 5000 :) > >Of course this was without using imperative haskell additions. If you >are functional, then better write the whole thing functional, if not then >use an imperative language :) > >Language *does* matter. It isn't the "language". It is the _implementation_. We have had basic interpreters and basic compilers. The compilers were as good as any other language compilers in terms of speed. The issue is does the language compile to native machine language for the target architecture, or to some sort of intermediate code (like pascal and java do), and does the compiler have a decent optimizer. IE FORTRAN on the right machine with the right compiler is just as fast as C or any other compiled language. > >>On November 13, 2002 at 13:35:51, Robert Hyatt wrote: >> >>> >>>(3) programming language features. loops. block if-then-else structures, good >>>access >>>to native hardware data units, etc. Unfortunately, the more complex the >>>language, the >>>worse the optimizer, which is why C is quite popular. Very simple programming >>>language, >>>fairly close to assembler-level stuff, makes it fast/efficient. More abstract >>>languages (PL/1, >>>ADA, and off into the _really_ abstract stuff like prolog, snobol, lisp and so >>>forth) tend to >>>produce slower executables. >>> >> >>Ada is not more abstract than C, if you don't want it to. On the other hand, it >>is if you want it to. >>In fact it has way better support for near-hardware programming. You can >>specifiy more precisely and portably how many bits some field of a record is, >>and how it should be interpreted etc. >> >>/David
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.