Author: Vincent Diepeveen
Date: 19:22:18 09/15/01
Go up one level in this thread
On September 15, 2001 at 21:42:18, Dieter Buerssner wrote:
>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.
Oh sorry, didn't realize JAVA was that a horrible language, thanks
for the explanation!
>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.
diep NEVER has run faster with -O with gcc, always -O2 was tens of
percents faster than -O.
You are using inline assembly and bitboards, i remember Bob complaining
about -O being faster too?
>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)
>
>?
yep
>>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
yep
>will produce something like
>
> or eax, edx
> jnz some_label
>and does not have the disadvantages of your "+" method.
i know
>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))
just seeing that code i already fall laughing down as the
alternative to not using bitboards on 32 bits processors
seems smarter to me!
>which can save a branch compared to
>if (((a.word1&b.word1)||(a.word2&b.word2))
this is exactly what i mean, a compiler being that smart that it
can save a branch i must see first!
Also compilers have the bad habit to do fallthrough wrong.
Of example if i code something next:
if( !(seldom-taken-pattern) )
goto fallthrough;
else {
evaluate pattern;
}
To my big horror all compilers using -O2 are saving out the
'goto' statement and then fallthrough prediction goes wrong.
I am not a stupid programmer compilerbuilders, i make many mistakes
but in the end it is always smart code, if i write down a goto then
i sure have a reason to do it!
>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
I have a kind of feeling that i know what you teach...
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.