Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: assembly--not really that fast

Author: Eugene Nalimov

Date: 20:54:27 01/13/02

Go up one level in this thread


On January 13, 2002 at 16:27:01, Tom Kerrigan wrote:

>On January 13, 2002 at 10:22:52, Robert Hyatt wrote:
>
>>1.  You know more about the program than the compiler.  No bounds-checking
>>on "switch" type statements is necessary.
>
>What bounds checking or "switch type statements" are going on in a C program if
>you don't explicitly put them in?

  switch (x) {
    case 0:
      ...
    case 1:
      ...
    case 2:
      ...
  }

Good compiler will generate something like:

  if (x == 0)
    ...
  else if (x == 1)
    ...
  else if (x == 2) // That condition is not necessary
                   // if x can be only 0, 1, or 2
    ...

In more general case, compiler have to generate even more complex check, i.e.

  if (((unsigned)(x-(lower value)) > (unsigned)(upper value - lower value))
    goto default;

>>2.  you know whether a value can be positive, negative, or both.  The
>>compiler can't.
>
>Why does this matter? Just deal with 32 bits (or whatever your word size is) and
>call it good.

On 64-bit system you can avoid sign extension if you know that the value is
non-negative. Sometime you can achieve similar effect in C casting the value to
the unsigned, but code becomes uglier than even assembly one.

>>3.  you know whether a value can exceed (say) 127 or not.  The compiler can't.
>
>Again, why does this matter?

Once again, to avoid ZXT/SXT.

>>4.  You know how many registers the CPU has and can design code around that,
>>while C doesn't give you such control.
>
>You can change the C until it produces the assembly that you want.

That can be hard in the marginal cases. If your compiled program needs less
registers than target CPU have, than it easily can be at least not worse than
assembly program. If both your program and assembly program run out of
registers, usually there is no much speed difference, too. But in marginal case
you can see huge difference -- e.g. on x86 compiler was not able to fit
everything into 7 registers (it wanted 8, but there is no 8th register there, so
there are spills), but programmer was able to slightly rearrange the code and
still squeeze everything on 7 registers...

>>5.  you know exactly which registers procedure "x" will destroy, so you don't
>>have to save everything before calling it.  If you are careful, you don't have
>>to save _anything_.
>
>The really strict calling conventions that you're thinking of here are no longer
>present in today's compilers.

Here you are only partially right... There are still cases where compiler have
to honour standard calling conventions.

And I can add

6. Usually programmer knows much more about possible aliases in his program than
even the best compiler can find out.

But Tom is partially right, too -- today's compilers are much better than ones
from 10 years ago. I am not talking about vectorizers, obviously major compiler
vendors started to look at them only recently, but for the control-heavy integer
code current compilers should produce reasonable code.

Eugene

>-Tom



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.