Author: Robert Hyatt
Date: 07:55:42 02/17/04
Go up one level in this thread
On February 17, 2004 at 10:04:12, Daniel Clausen wrote: >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. C was chosen (by me) for two reasons. (1) it exists on every platform I know, and it is standard on every platform. Other languages (such as PL/1) would be even better, but they don't exist for every platform, and they are not available on most machines as distributed, they have to be purchased later. (2) It produces efficient code. The higher-level the language, the more likely you are to get sloppy binary code out of it... > > >>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. > Not at all. You write something in C, I will re-do it in asm and make it faster. I don't even need specifications. I can direct you to a team of people at Lawrence-Livermore labs that do this daily. Bring 'em your slow fortran code, they deliver to you a faster program with some asm pieces. >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. I won't disagree. But once I get the ideas firmed up, lower-level-language here I come. Because then I want speed... A good question: "why do you suppose nearly _all_ current programs are written in C? (the only exception I can point to for a successful program was Cray Blitz which was fortran)???" Answer -> performance. A few have even gone all the way to assembly (Older Fritz versions for example). Again for performance. Not because they like asm programming. > >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.