Computer Chess Club Archives


Search

Terms

Messages

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

Author: Don Dailey

Date: 08:13:24 09/29/98

Go up one level in this thread


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:
>>>>>[snip]
>>>>>>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*
>>>>>>speed.
>>>>>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).
>>>
>>>--Jon
>>
>>
>>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 -----




This page took 0.05 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.