Author: Robert Hyatt
Date: 13:03:57 02/16/04
Go up one level in this thread
On February 16, 2004 at 15:54:11, Uri Blass wrote: >On February 16, 2004 at 15:38:01, Robert Hyatt wrote: > >>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 think that a smart compiler should be able in the future to pay attention to >the fact that the values are in a certain range(when the programmer run the >program in debug mode) and ask the programmer if it is right to assume that it >always happen. > >Same for other things that you mention. > >Uri There are other problems. For example, in a case/switch block in C, the semantics of the language say that if none of the cases are matched, the statement after the block is executed next. It is not so easy to remove that basic semantic requirement from the language safely. And asking the user is not a good idea in a program with 7,000,000 source lines, and 60,000 case statements. :) Another issue is the ! operator. The ANSI standard says that if you make the assignment "x = !x;" then if x is zero, !x is 1, but the ugly part is that if x is not zero, !x is zero. That not zero is ugly. That's why I use XOR to flip wtm in crafty. wtm ^= 1; is way faster than wtm = !wtm; And the compiler can't do much about it... Of course _I_ know that wtm can only be 0 or 1, the compiler doesn't know that and since the wise heads that developed the C standard didn't think it necessary to have any type of "boolean" data type, we just "make do with what we have." :) That's a couple of reasons why a good programmer can whip a bad programmer in terms of execution speed. And why an assembly programmer can usually whip _both_ if he is any good. :)
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.