Author: Robert Hyatt
Date: 12:38:01 02/16/04
Go up one level in this thread
On February 16, 2004 at 15:24:19, Frank Karger wrote: > > Hi Robert, > > some time ago I was looking around to find out if > the language I have chosen in the past (C/C++) > was a good choice. > Unfortunately I found out that this is not the case. > > If you compare languages by speed, C is normally the > best (leaving Assembler out). > But how much is it better ? > If you look here > http://www.bagley.org/~doug/shootout/craps.shtml > (a big Computer language Comparison) > You can see that the difference in mere speed is very > small. The comparison has a basic flaw. The purpose for using a high-level language is to reduce development time. That isn't what is done in these benchmarks. Here, everyone uses their favorite language and tweaks and twiddles to produce the cleanest code possible. And, on occasion, they are close in performance. But then why go to the trouble if development time is not an issue. And no matter _what_ the assignment, the right assembly programmer will come in first, every time. Unless you measure development time, of course. :) > > On the other hand development time is a strong > argument. For example if you want to write the best > chess program in the world you mainly have to try > many ideas and - if you are lucky - your ideas will > form the best program. > > Some studies show that development time in languages > like Lisp is about half than in C, Java or C++. > e.g. http://www.algo.be/cl/TEE-lisp/31837187622993390/index.htm > > So, we have about 5% loss in speed (perhaps even less if you > look at the Ocaml-Compiler) but 100% gain in productivity. > > Lets say, you are working about 10 years improving crafty. > Do you really think that if you could have done the work > for 20 years in that time that 5% speed are a strong argument ? Yes. For example. Threads? How in lisp? Portability? There isn't a lisp on every machine. So while development time is an issue, if you play your cards right, C works just fine. That's why I have all the macros in chess.h, it simplifies the coding a lot, hiding some tiny details that I don't need to see over and over. Also, I would not buy "5%". I wrote assembly on the Cray that typically beat their FORTRAN compiler 2-3-4-5X. And they have arguably the best optimizing/vectorizing/etc compiler on the planet. But it just can't touch a good human that knows the program inside out. IE I know when values are in a certain range, the compiler doesn't. I know when signed/unsigned are equivalent but the compiler has to convert/sign-extend. I know when case variables can't be outside a particular range, the compiler doesn't. The list goes on and on and on. Remember, some _human_ wrote the optimizer, and he made lots of compromises to make sure it _always_ produces correct code. A good programmer can always produce correct code as well, with none of the extra stuff thrown in. > > Frank
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.