Re: compiling glaurung
Posted: Fri Jul 20, 2007 10:00 am
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.Tord Romstad wrote: The warnings are caused by code like this: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".Code: Select all
inline bool Position::pawn_is_doubled(Color c, Square s) const { return this->pawns_of_color(c) & squares_behind(c, s); }
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.
No, it is almost certainly because you have generated a executable in debug mode.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?
Tord
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