Computer Chess Club Archives




Subject: Re: Why is assembly more effecient than C?

Author: Komputer Korner

Date: 11:05:36 09/30/98

Go up one level in this thread

On September 30, 1998 at 09:52:05, Robert Hyatt wrote:

>On September 30, 1998 at 03:32:45, Dave Gomboc wrote:
>>On September 29, 1998 at 11:13:24, Don Dailey wrote:
>>>On September 29, 1998 at 00:57:32, Dave Gomboc wrote:
>>>>On September 28, 1998 at 14:12:25, Robert Hyatt wrote:
>>>>>On September 28, 1998 at 10:06:42, Jon Dart wrote:
>>>>>>On September 28, 1998 at 09:17:09, Robert Hyatt wrote:
>>>>>>>On September 28, 1998 at 03:01:19, Danniel Corbit wrote:
>>>>>>>>On September 27, 1998 at 18:18:25, Robert Hyatt wrote:
>>>>>>>>>not exactly.  IE I can't imagine that a C compiler + optimizer can beat
>>>>>>>>>hand-tuned asm code, even if I write both the C and the asm code.  The
>>>>>>>>>guys that write the optimizers are good, but they aren't as good as
>>>>>>>>>someone that has been programming asm code for 30 years...
>>>>>>>>>The main reason everyone doesn't use ASM code is portability, *not*
>>>>>>>>Risc C compilers can almost always outdo hand written code except for very small
>>>>>>>>snippets.  For CISC I agree with you, especially Intel x86, since there are so
>>>>>>>>many good Intel assembly programmers.  For thousands or millions of lines of C,
>>>>>>>>an equivalent ASM is very hard to produce for Risc machines.
>>>>>>The Intel processors now do many of the tricks that RISC processors have
>>>>>>traditionally done. It used to be that you could just get the processor manual,
>>>>>>add up the instruction times, and figure out how fast your code would run.
>>>>>>Now that's not true anymore. So writing optimal assembly language is
>>>>>>non-trivial, even for the Intel machines. (However, I would add that few
>>>>>>compilers do a really great job of register allocation - which is quite a bit
>>>>>>harder on Intel than other architectures - so that is one area where a human can
>>>>>>improve on the compiler).
>>>>>There are other things too.  IE how many chess programmers do an x=x*2.5 in
>>>>>their evaluation function?  None?  Better check out cray blitz.  And the reason
>>>>>is buried in the Cray architecture and how floating point stuff is done in
>>>>>parallel with integer stuff, so that I can do x=x*2 and y=y*2.0 in the same
>>>>>time it would take to do just x=x*2...  but the compilers don't know whether
>>>>>you can take a float and use it as an int, or vice-versa, while *I* do because
>>>>>I know how the number will be used later, and where the important part of the
>>>>>number is (whole or fraction or both).  The compiler *always* has to be
>>>>>conservative and once it has a float, it has to stick with a float to avoid
>>>>>losing those fractional bits, even when they will be zero (but it can't know
>>>>>that of course.)
>>>>>That's the point.  I *know* *all* about the program and the values it is
>>>>>computing.  The compiler doesn't...
>>>>I think that if somebody had enough time to write it all in assembly, they might
>>>>do a better job than a top-notch compiler.  That's a pretty big if though, it
>>>>might take a lot longer than a human lifespan.  Anyway, I think more often the
>>>>compiler will be better.  If I may make an analogy :), let's use computer chess.
>>>Actually, you are wrong here.  Fritz is just one example of a carefully
>>>coded machine program.  I have talked to Franz and he understands all
>>>the instruction scheduling issues for each processor he writes for.
>>>And he specifically targets an individual platform, something that is
>>>commonly available but near the cutting edge.  That is why he rewrites
>>>relatively frequently.
>>>I have written programs entirely in assembly too (but not the interface)
>>>It is more tedious, but not more difficult (if that makes any sense.)
>>>My impressions are that it really doesn't take much longer at all to
>>>write code but debugging gets harder.  This assumes you have already
>>>developed some proficiency in assembler and have good tools.  One other
>>>issue is that c has libraries of routines already available but so can
>>>assembly.  Most of these libraries will not affect a chess program very
>>>much but will affect the interface, which will be written in some high
>>>level language if you are wise!
>>>The other issue of course is understanding instruction scheduling,
>>>timing issues and caching issues.
>>>With modern processors it gets harder to match a compilers ability
>>>to do these things. But if you understand the issues well you can do
>>>much better and it will not take even close to a lifetime.
>>>You would be surprised that something that seems so complicated is
>>>not really once you break it down and learn to understand the issues.
>>>- Don
>>>---- I snipped the rest -----
>>I didn't convey my thoughts clearly enough, I was not suggesting that
>>implementing a chess program in assembly would take a lifetime.  When I wrote
>>the first statements I was thinking about the 5 million lines of C++
>>megaprojects out there.
>>If the human assembler has so much more expertise than the machine assembler,
>>instead of hand-coding the end software, perhaps the human assembler should be
>>"educating" the machine assembler.
>>Dave Gomboc
>The problem is that the 1/2 million lines of code in a good code
>optimizer would become 500 million lines of code, with more bugs, more
>mistakes, and would be unusable.  It would be *very* difficult to make
>an optimizer do what a good human can do.  Yes, they can be more
>thorough, once they do peephole optimizing, because they can shine that
>"peephole" over millions of lines of code which would be tedious for a
>human... but the human wouldn't do it for the entire code, only the 10%
>that the human knew needs it.  Hence we now have "profiling optimizers"
>that run a program then figure out which parts are "hot spots" just like
>humans do.  But making an algorithm optimize like a human is quite a task.
>I doubt I'll be "replaced" in my life-time.  :)

What about a chess compiler? Obviously you would need one for each platform.

This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.