Author: Robert Hyatt
Date: 13:59:29 01/17/04
Go up one level in this thread
On January 17, 2004 at 16:26:59, Russell Reagan wrote:
>On January 17, 2004 at 15:43:27, Robert Hyatt wrote:
>
>>I don't see how this can be the same thing we were talking about. To use
>>an "immediate value" the value must be fixed at _compile time_. Because only
>>then can the compiler fill in an immediate operand directly into the
>>instruction, rather than doing a load from memory..
>>
>>All I can see your "const" declaration doing below is telling the compiler
>>"If I modify from or attacks in this function, then produce an error as it
>>has been declared to be a constant and is not modifiable."
>>
>>Am I missing what you asked???
>
>I'm not really talking about the issue of immediate values (rather, const
>intermediate values). I am thinking that since the intermediate value 'attacks'
>is const, the compiler can do one of two things with the code I posted:
>
>The same thing I posted originally:
>
>// In movegen...
>Bitboard rooksLeft = friendlyRooks;
>while (rooksLeft)
>{
> const int from = FirstOne(rooksLeft);
> const Bitboard attacks = RookAttacks(from); // <-- Store intermediate value
>
> // Generate captures
> Bitboard moves = attacks & enemyPieces; // <--- Use attacks once
> while (moves)
> {
> // Generate the captures...
> }
>
> // Generate noncaptures
> moves = attacks & emptySquares; // <--- Use 'attacks' again
> while (moves)
> {
> // Generate the noncaptures...
> }
>}
>
>Or this (changes on the lines with arrows):
>
>// In movegen...
>Bitboard rooksLeft = friendlyRooks;
>while (rooksLeft)
>{
> const int from = FirstOne(rooksLeft);
>
> // Generate captures
> Bitboard moves = RookAttacks(from) & enemyPieces; <--- Call RookAttacks()
> while (moves)
> {
> // Generate the captures...
> }
>
> // Generate noncaptures
> moves = RookAttacks(from) & emptySquares; <--- Call RookAttacks()
> while (moves)
> {
> // Generate the noncaptures...
> }
>}
>
The compiler should do that automatically. That is a common optimization
to avoid doing extra work. One problem is that if you use two procedure
calls, they can't be optimized away since it is possible that they return
different results for the same input values (random is an example).
The discussion was about speed and how assembly language might look, where
the compiler could use an immediate operand or do a load from memory...
>Instead of storing the intermediate value of RookAttacks() in 'attacks', you
>could call RookAttacks() twice. Depending upon how expensive the function you
>are calling is, the compiler may decide to call the function twice (and not save
>the intermediate value through the whole function, which might free up a
>register or something), or the compiler might decide to store the intermediate
>value if the function will be more expensive to compute.
You should always do that, although there is usually a compiler option to
tell the compiler F() always returns the same value given the same inputs
so that it can avoid multiple calls with the same input values...
>
>I am just saying that it makes sense to me that the compiler can make that
>decision better than I can (this example might be simple, but others might not),
>so I store the intermediate value in a const variable, and the compiler can
>substitute a function call (probably inlined) every place the intermediate
>variable is used (like a macro), or it can call the function once and store the
>value and use that over and over.
Without help it can't do what you want, just think what would happen if
you did that to a random() call. :)
>
>I don't know whether this is a good idea or not. Maybe I have too much faith in
>the compiler's optimizing abilities.
This page took 0.01 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.