compiling glaurung

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Eelco de Groot
Posts: 4027
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: compiling glaurung

Post by Eelco de Groot » Fri Jul 20, 2007 8:00 am

Tord Romstad wrote: The warnings are caused by code like this:

Code: Select all

inline bool Position::pawn_is_doubled(Color c, Square s) const {
  return this->pawns_of_color(c) & squares_behind(c, s);
}
In this function, this->pawns_of_color(c) and squares_behind(c, s) are two bitboards, and doing a bitwise and ('&') between the two bitboards gives a third bitboard. But because the return type of the function is 'bool', this bitboard must be coerced to a boolean (a zero bitboard will become 'false', and any nonzero bitboard will become 'true'). This is an expensive operation, which is why your compiler gives a "performance warning".

I think these warnings can be safely ignored. All these little boolean functions are inlined, and the compiler should be able to deduce from the context that it doesn't need to do the coercion to 'bool', because the return value is usually only used as the condition in an 'if' statement.

It would probably be possible to avoid all these warnings by changing all these functions to return bitboards rather than booleans, but I prefer using booleans because it seems more conceptually correct. My own compilers (GCC and the Intel compiler) don't emit these warnings.
The first executable does not crash however, and I was sure glad of that! The output I get is still very slow, could that be because bitboards are not working?
No, it is almost certainly because you have generated a executable in debug mode.

Tord
Thanks for the explanation Tord. Maybe if the Visual C++ compiler gives these warnings, it does not know it can safely use the bitboard value to test the if statement, and the other Intel and GCC compilers do know? It could be worth checking that, if it only means temporarily changing the return types of the functions comparing bitboards. If it really is an expensive funtion and the compiler is not smart enough, it might give a speed-up.

It would never happen in a Pascal type language compiler I think, the compiler changing any return type of a function on its own? I would think that it goes against the whole grain of these languages, to do type checking always and be strict about it, to avoid any programming errors.

I tried looking up what the mention of the warning using an int for size_t in uci.cpp(122) is about, it must be something in the string reading code in the include files, size_t is not anywhere in your own code. I thought if the strings used in setting the options are not very long it should give no problem, maybe this integer type conversion also differs per compiler. I found this, contextually helpful for me, reference about the same warning, but probably not much new in it for you Tord: http://discuss.joelonsoftware.com/defau ... 4.199991.7

It feels great to actually be able to do a compile of Glaurung! Thanks to the help of all the experts, it was not as difficult as I expected. Thanks for your program Tord!

-Eelco

wgarvin
Posts: 838
Joined: Thu Jul 05, 2007 3:03 pm
Location: British Columbia, Canada

Re: compiling glaurung

Post by wgarvin » Fri Jul 20, 2007 3:14 pm

Code: Select all

inline bool Position::pawn_is_doubled(Color c, Square s) const { 
  return this->pawns_of_color(c) & squares_behind(c, s); 
} 
An easy way to suppress the conversion-to-bool performance warnings in code like this, is to add a comparison with zero to the end of the expression. Then you are producing a bool yourself instead of leaving it to the compiler to do it for you:

Code: Select all

inline bool Position::pawn_is_doubled(Color c, Square s) const { 
  return (this->pawns_of_color(c) & squares_behind(c, s)) != 0; 
} 
A good compiler will probably? generate the same code from this as it does from the version above. A good optimizer will probably? be able to optimize away the comparison when using it as the condition of an if or while statement) when it inlines this function.

If writing code from scratch, you may prefer to avoid conversions to bool, except where you specifically need a 0 or 1 result for indexing or something. In that case, I would avoid giving predicate-like names to such functions, so that you don't accidentally try to use it like a boolean.

Code: Select all

inline Bitboard Position::get_doubled_pawn(Color c, Square s) const { 
  return this->pawns_of_color(c) & squares_behind(c, s); 
} 

ed

Re: compiling glaurung

Post by ed » Fri Jul 20, 2007 4:56 pm

Uri Blass wrote:I get again and again
"fatal error C1083: Cannot open include file: 'windows.h': No such file or directory"
I downloaded and installed MSVC5 too and got the same error message. I checked the harddisk, there is no "windows.h" installed. What do I miss ?

Ed

Uri Blass
Posts: 8332
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: compiling glaurung

Post by Uri Blass » Fri Jul 20, 2007 5:02 pm

ed wrote:
Uri Blass wrote:I get again and again
"fatal error C1083: Cannot open include file: 'windows.h': No such file or directory"
I downloaded and installed MSVC5 too and got the same error message. I checked the harddisk, there is no "windows.h" installed. What do I miss ?

Ed
You missed step 2
Install the Microsoft Platform SDK.

http://msdn.microsoft.com/vstudio/expre ... usingpsdk/

Uri

Post Reply