Archived

This topic is now archived and is closed to further replies.

BOOL vs bool speed

This topic is 4957 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am curious which is actually faster in MS C++. Don''t divert this into a discussion about which I should use style wise. I searched this site for answers to this question which has been asked before and nobody actually answered the question. They just diverted it into dogma about how bool is better because it is the standard.

Share this post


Link to post
Share on other sites
Faster? Hmm, I really doubt you''re going to get a noticeable speed difference using one or the other. I''m assuming BOOL is just a define to char ... or maybe to int, who knows. Either way, won''t it get blown up to an integer anyway, regardlessif it''s a char or an int in the first place?
Well anyway, don''t get hung up on trying to optimize this kind of crap IMO. Concentrate on writing efficient algorithms instead.

Share this post


Link to post
Share on other sites
Yeah, basically what Red Ant said. BOOL is a typedef for int, thus, on a normal platform with MS VC (version 6, I''m assuming, I don''t know about the others), a BOOL is 4 times as large as a bool. If you have a large array of these values, then it would probably be best to use bool, to save space. In any other situation, though, there''s no reason, really. Microsoft made BOOL an int instead of a char or bool so that it would be identical to the word size of the standard processor (32 bits). This may add a small small bit of performance to programs in certain areas. Usually, none of this is worth worrying over.

Of course, in the one situation mentioned above, where you have a really large array, and you really need to save space, then it would probably be best to use the bitwise operators to actually get and set each individual bit. Compared to using BOOL, you would only use 1/32 of the total space BOOL would use. But it''ll take a bit more processing to get/set the values. Usually nothing significant, though, especially when space is more valuable than time.

Share this post


Link to post
Share on other sites
I would guess that would be platform specific and you will never know for sure and thats why there most probably isn''t a definite answer.

BOOL is just a type alias of an integer and on 32 bit architectures will be 4 bytes big on high/lower bit archs it will be something else, its not portable if you wonted to use it non MS OSs you''ll need to typedef it yourself. I guess it was created because the Win API is a C lib and C doesn''t have built-in boolean type, unless one has been add in C99 now.

bool is a built-in primitive type of C++, its 1 bit long, because it''s a built-in type it will work on all C++ compilers and is more type safe.

I don''t much about IA-32 type architectures but i do know that Microcontrollers support built-in bit operations and they take one cycle to set/clear a bit but if you used a whole register as your boolean it may take 1 or 2 cycles depending on the operation and its operands.

I dont think this is a matter of style, if your using a language you use it''s features, if your programming in C++ choosing BOOL over built-in bool and using it as it''s intended to be used is silly.

Share this post


Link to post
Share on other sites
quote:
Original post by Warpstorm
I am curious which is actually faster in MS C++.

Don''t divert this into a discussion about which I should use style wise. I searched this site for answers to this question which has been asked before and nobody actually answered the question. They just diverted it into dogma about how bool is better because it is the standard.

Well, rather than diverting it into a style discussion (where bool obviously wins) I''m going to divert it into a premature optimization discussion.
It really, really, really doesn''t matter which is faster. The speed difference is not going to be noticeable. Use bool. When you''re closer to completion, profile your code. If by some miracle your code is so well written that using bool is actually in the list of the top 20 things that makes your code slow, then change the type. If you can''t tell whether using bool is slowing you down, then use a typedef instead (so you can easily change all occurances) and test both types.

There''s another reason that I can''t give you a straight answer: It depends on how the variables are being used. For example, in some cases, using BOOL may push you over a size boundary, and slow you down, whereas in other cases, using BOOL may push your data just up to a size boundary and make the code faster. Yet another reason is that the speed differences will depend on the machine architecture.

John B

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Red Ant
Well anyway, don''t get hung up on trying to optimize this kind of crap IMO. Concentrate on writing efficient algorithms instead.


This isn''t really about optimization, but rather to settle an argument. What is faster using bools or BOOLs on a Microsoft Windows environment? Cross platform is of absoulute no concern to us.

Share this post


Link to post
Share on other sites
quote:
Original post by snk_kid
bool is a built-in primitive type of C++, its 1 bit long, because it''s a built-in type it will work on all C++ compilers and is more type safe.

The size of a boolean is, like most data type sizes in C++, not exactly defined. You are guaranteed that 1<=sizeof(bool)<=sizeof(long) (Stroustrup, The C++ Programming Language, 3rd edition, 4.6); since there is no upper bound on a long, and since you are guaranteed that a char holds at least 8 bits (and sizeof(char) is 1 by definition), a bool is at least 8 bits. On my platform it appears to be exactly 8 bits; on yours, it may or may not.

It is true that a std::vector<bool> is a bit vector, with all the good and the bad that it implies ...

Share this post


Link to post
Share on other sites
It''s also the case that compiler options may change the size of bool, correct?

If you are trying to settle a debate, why not definitively test it as someone else suggested. Why bring it up in these forums where you can never get a straight answer and in some cases you will get simply wrong information (like a bool only takes up 1-bit)

Regards,
Jeff




[ CodeDread ]

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
This isn''t really about optimization, but rather to settle an argument. What is faster using bools or BOOLs on a Microsoft Windows environment? Cross platform is of absoulute no concern to us.
It pretty much completely depends upon A) what processor you''re using, and more importantly B) how you''re using booleans in your code. A BOOL might be faster on an average processor for algorithm 1, while for algorithm 2, a bool will be faster, using the same average processors. Heck, on a few processors, it might switch on a few algorithms. In the end, it is really hard to say which is faster. The most definite situation I can think of, as I said earlier, is when you have a huge amount of booleans. In that case, it is better to reduce space, partially just for the sake of reducing space, but also to help with keeping everything in the cache, not having to use virtual memory, etc. Those sorta things will affect speed noticeably, but only if you have a large enough number of booleans for it to matter. Otherwise, it''s pretty hard (and pointless) to say which is faster.


Most of the greatest evils that man has inflicted upon man have come through people feeling quite certain about something which, in fact, was false.

-Bertrand Russell, Unpopular Essays, "Ideas That Have Harmed Mankind"

Share this post


Link to post
Share on other sites
quote:
Original post by Red Ant
Well, can''t you just run 1 million bool comparisons using both types and take the time?


No, this is completely pointless.
Read what JohnBSmall said. If you don''t understand his reply, then you shouldn''t even be thinking about these kinds of optimisations.

And if you need to worry about an array of bools taking up too much space, then maybe you need to rethink your overall method.

Share this post


Link to post
Share on other sites
It think usage really depends on where your primary bottleneck hits at.

If you''re short on memory, the smaller data size of bool is probably a good option, but using BOOL avoids the conversion to a 32 bit integer, which will probably cost a few clocks.

One thing to keep in mind though, is that within the next 5 years those BOOLs will become 64 bits long as 64 bit archetecture takes hold in desktops.

Granted, 64 bit systems should be able to have more RAM anyway, but that''s not likely to affect how much RAM is in desktops anytime soon. Within 5 years I''d be surprised if the average user has more than 1-2GB of RAM.

Then again, the conversion from a byte to a 64-bit integer might take more clocks as well...so...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
FWIW, a quick test shows that BOOLs are about 15% faster than bools in a simplistic test that passes a bool into a function, sets a bool to the value, tests it, and returns a bool and the equivalent with BOOLs.

Why?

The assembly generated does an AND of the bool with 0FFH every time it is using it but not when it it is using the BOOL.

This was with VS 6.0 optimized.

Okay, this isn''t the order of magnitude speed up that a better algorithm can sometimes give you, but...

Share this post


Link to post
Share on other sites
BOOL's ought to be faster unless you are using millions of them, bool require more bit fiddling to guarantee they are either 0 or 1. int's (BOOL) are false when 0 and true otherwise (typically -1 is used for true since this sets all the bits to 1).

BOOL is a Win32 typedef, whereas bool is a distinct C++ type. Despite the apparent trivial difference, BOOL cannot be substituted for many cases where bool is truely needed.

[edited by - Magmai Kai Holmlor on May 19, 2004 10:49:56 PM]

Share this post


Link to post
Share on other sites