Author: Koundinya Veluri
Date: 00:49:59 09/28/03
Go up one level in this thread
On September 28, 2003 at 02:10:16, Gerd Isenberg wrote: >>For the function returning bool, the best I could do is return c & 1, which >>generates one and operation. Since the same code is generated for isBlack1() and >>isBlack2(), I see no advantage in using BOOL. > >Ok, it may depend on the callee with inlined functions. >IIRC the ms-compiler does some optimization with int: > >if ( isBlack(c)) >... >; c = ecx > test ecx, ecx > jnz _isblack > >instead of >; c = ecx > xor eax, eax > test ecx, ecx > setne al > .... > test al, al > jnz _isblack > That's true, if you store the bool result, do something else, then use the result in a conditional, there could be some extra instructions, but this is easy to fix: by not converting to bool until the actual conditional, where only a test instruction would be done. As far as I can see, the setxx instructions would only be needed when you convert a larger type to bool and store it in a bool (not use it immediately). If the result is used immediately in a conditional, the setxx instruction disappears and all that is left is one test instruction, the same as for using int. So I guess one should be more careful when coding with bools instead of BOOLs making sure not to fall into these traps. However, I still believe that, when properly coded, bool and BOOL will be equally fast. For a case like isBlack() when the function is inlined and really fast, there is no need to store the result. It would be more optimal to do if(isBlack()) everywhere, in which case there is no difference between int and bool. Then there's the case where you have a really slow function that essentially converts an int to a bool. You'd probably want to exec the function once, store the result, and use it later in conditionals. The function either does the conversion from int to bool directly and then does some other slow stuff, or it has a lot of decision making or calculations to decide what the bool result should be. In the latter case, it would not matter whether the function returns bool or BOOL because the decision making part removes the necessity for the extra setxx instructions involved in converting int to bool. In the former case, that is if the function converts the int directly to bool and then does other slow stuff, the conversion part can be isolated into a fast inlined function and used directly in conditionals later (instead of storing its result), which would be equally fast as using BOOL. So I think if coded properly, there would be no difference in speed. >I agree that it is a compiler "fault" not to use the zero flag immediatly. >Same for boolean mapping with bit testing. > >> >>If you are saying that no test is necessary for isBlack1(), then that's the same >>as returning c. But then there is no point to the function isBlack1(). You can >>just use the color directly in the calling function. > >You are right, a dumb sample... >I mean immediate conditional statements with these boolean inliners, >instead >if ( color == WHITE ) >if ( color.isWhite() ) > Not at all, that was pretty much implied since there would be no reason for having a function called isBlack(), other than to put it in a conditional expression. My compiler produces the same code for int and bool though, even (I should say especially) when the functions are used in conditionals (if the result is not stored beforehand, as you pointed out). >>Also, there will be a >>problem in isWhite1() where basically a conversion to bool will be necessary. >> > >Yes, one may use "!c" or "c^1" or "1-c". >My point with "bool" is, that there are often not necessary SETxx instructions. > You may be right. My guess is, for every "special case" where int performs better, it is also possible to restructure the code to make the bool version perform equally well. >>I also tried making the colors bool but when I use a bool as an array index, >>this compiler generates a movzx to zero the rest of the register and then uses >>the whole register as the index. Instead couldn't it just use the partial >>register as the index? That would be a possible solution too, if that worked. >> > >No, x86 addressing modes only use 32-bit registers in 32-bit mode. >On Opteron one may use 32- and 64-bit registers in 64-bit mode. >Signed int32 is sign extended at runtime and need some extra time. > Oh ok, I didn't know that. Koundinya
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.