Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Move generation question for the big boys

Author: Dieter Buerssner

Date: 18:42:18 09/15/01

Go up one level in this thread


On September 15, 2001 at 16:17:52, Vincent Diepeveen wrote:

>On September 15, 2001 at 15:23:29, Bruce Moreland wrote:
>
>>On September 15, 2001 at 14:30:40, Vincent Diepeveen wrote:
>>
>>>On September 15, 2001 at 11:14:36, Sune Fischer wrote:
>>
>>>>   bb ^= mask[to_square];        // remove the bit
>>>>
>>>>   movelist[++counter].from=from_square;
>>>>   movelist[counter].to=to_square;
>>>>   movelist[counter].piece=QUEEN;
>>>>   movelist[counter].capturedpiece=enemy.piece[board.id[to_square]];
>>>
>>>this looks ugly. Using a pointer here would be way faster.
>>
>>Not necessarily.  If the "counter" variable is enregistered by the compiler, you
>>end up with about the same thing as if you used a pointer, but it also depends
>>upon how large the elements of "movelist" are.
>
>If compilers optimized very well, then our problems would be solved Bruce,
>we could go write our programs in JAVA or C++ and let the compiler handle
>the problems of not allocating and removing objects.

I don't agree. There are too many priciple things that just cannot be optimized,
as one would like. Especially when pointers come into play. If you take the
adress of an object at some point, many optimiatation possibilities are just
gone, because of alias issues. The same is true for the references pointed out
in the other post.

Actually, I found that gcc optimizes array code too well too often for x86 (not
for alpha or MIPS, when I tested last). Often this will need additional
variables for the pointers magicially used, where the indexed access is de facto
free often on x86, as Bruce has explained. Most of my numerical code runs faster
when optimized with -O with gcc, instead of optimizing it with -O2, where, at
the time I checked, all array code was converted to pointer code.

However, in the above example counter seems to be a global variable. Here most
probably a pointer really will be faster. And, in exact this case, I also would
use a pointer.

>Also we would be able to use old Qbasic code in a very efficient way then.
>
>That's not what happens however. Usual it's smart to NOT trust the compiler.
>
>When patterns get complex then i saw that visual c++ makes huge optimization
>errors.
>
>Like if i check for 2 non-array/pointer entities for being zero:

You mean

  if (a == 0 && b == 0)

?

>if( a & b )
>  then do this and that;

Which is neither the same as

if (a & b)

or a

if (a && b)

> to produce some crap assembly:
>  CMP EAX,0
>  JNZ LOOP
>  CMP EDX,0
>  JNZ LOOP1

integral type a, b;

  if (!(a|b))
   do this

will produce something like

  or eax, edx
  jnz some_label

and does not have the disadvantages of your "+" method.

And, to get a bit more on topic. Something like above can be useful for
bitboards, that are "home-made" by two 32 bit variables.

bitboard a,b

if (a&b)

can be coded as

if ((a.word1&b.word1)|(a.word2&b.word2))

which can save a branch compared to

if (((a.word1&b.word1)||(a.word2&b.word2))

Note the binary compared to the logical or.  Compilers I checked used the second
method internally, when using 64 bit types.

>In general the above construction makes no sense. Optimizing it with a
>pointer is always safer!

No.

Regards,
Dieter

"Premature optimization is the root of all evil in programming." C.A.R. Hoare



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.