Author: Robert Hyatt
Date: 19:31:43 11/14/02
Go up one level in this thread
On November 14, 2002 at 20:15:44, Vincent Diepeveen wrote: >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. Sure it can be. A java compiler that compiles directly to native machine language has no particular problems to overcome beyond those that a C compiler has to deal with. If you are talking about pointers, that's a non-issue. Cray Blitz didn't use pointers at all as they were not in Fortran prior to the fortran 90 specification... and it didn't hurt us one bit... nor the compiler... > >>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.