Author: Vincent Diepeveen
Date: 15:23:46 11/15/02
Go up one level in this thread
On November 14, 2002 at 22:31:43, Robert Hyatt wrote: >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... Java by definition compiles to bytecode and already lacking pointers and instead having some vague 'pointer from the system' stuff which means the same bugs but not the same speed, that's already more than enough to have a weak spot which will always show. Don't take me wrong however, i especially wanted to criticize functional languages. I have written thousands of lines of codes in functional languages. LISP i lucky could keep little, those ((((()))())(())) confused me just a bit too much :) I wrote however in an a look like functional language called Gofer (with Haskell extensions) and very clearly that gives for big programs (no one ever writes big programs with millions of lines of code in such languages or it is complete idiots who do it) it is impossible to ever efficiently compile it. A chessprogram is more than complex enough to not be able to optimize well. That's also a bit true for JAVA, but JAVA we can still see as a language where you can write imperative code (though it's object oriented cough cough), like in C++. Now that's still the same *league* like C and Fortran and obviously C++, but you have the possibility to use high level constructions in JAVA besides low level constructions. So i can't rule out that JAVA will become a huge success in the future. Yet it is trivial that C will be compiled faster. I can't give exact %. Of course very hard work on optimizers of JAVA (more than you need for C) will perhaps let it produce pretty efficient code, but still significant slower than C(++). However the real amateur league is the functional languages. Those are really very sick bad. Any comparision there is even done in an amateuristic way. Where JAVA programmers who compare JAVA versus C(++) know nothing from optimizing, nor how you can use pointers very effectively; there the amateur league isn't even capable of comparing more than 10 lines of code or so with each other and the intermediate code it produces because any routine bigger than that of course gets pushed on the stack :) >> >>>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.