Author: Daniel Clausen
Date: 07:04:12 02/17/04
Go up one level in this thread
On February 16, 2004 at 16:03:57, Robert Hyatt wrote: >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." > >:) Why not use a language where you have bool-support? The compiler knows it then and can produce the fastest code. >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. :) You forgot an important detail. The good ASM guy can only beat all the others if the algorithm to code is clear. In which area a certain chess engine belongs to is not at all clear. Depending on your goals it may very well be a good idea to use a high-level language and therefore have more time to test lots of new ideas than implementing it in C and be somewhat less flexible. Sargon
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.