Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: assembly--not really that fast

Author: Robert Hyatt

Date: 07:40:48 01/14/02

Go up one level in this thread


On January 13, 2002 at 23:54:27, Eugene Nalimov wrote:

>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
>

I never said they didn't produce "reasonable code".  I simply said that no
compiler can optimize as well as a good human...  Otherwise the compiler would
be _very large_ with the thousands of "special cases" that humans have learned
about by experience...

>>-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.