Author: Vincent Diepeveen
Date: 17:15:44 11/14/02
Go up one level in this thread
On November 14, 2002 at 13:01:55, Robert Hyatt wrote: Implementation matters a lot indeed, but functional languages will *never* be as fast as c(++). Also JAVA will *never* be as fast as c(++), no *matter* the implementation. >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 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.