When I'm doing a basic comparison of a value that can be one of only two values (e.g., 0 or 1, true or false), is it faster to use bool's or int's? Is the difference negligable or is there no difference at all?
Thanks.
When I'm doing a basic comparison of a value that can be one of only two values (e.g., 0 or 1, true or false), is it faster to use bool's or int's? Is the difference negligable or is there no difference at all?
Thanks.
No difference at all.
Thanks for the reply. I'll stick with Bool's then as it enforces only two values.
Anything basic like this you can bet the compiler would optimize it even if there were a difference. So there's no difference.
Depending on the circumstances enum fits what you said as well.
Warning: Have doubt in anything I post.
GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101
Actually, that's a good point and one I didn't consider. But I think the use is pretty basic and only requires two values. In this case I'm going for ultra basic collision detection. Within an array, a unit can either walk or not walk on a particular coordinate. This is really only a yes/no, true/false type situation as the array is used purely for collisions.
Best use bools, since ints could vary than in your case, especially if the user is inputting the coordinates.
Note that a vector of bools is a special type of vector. And, yes, using that will definitely impact speed.
Bool is smaller and hence can be faster if you are keeping large arrays of bools/ints, in terms of cache efficiency. For your purpose, a bool is self-documenting, too.
That said, since the x86 cdecl calling convention dictates that arguments smaller than 32-bit should be extended to 32-bit before getting pushed onto the stack (or does it not?). It could make your code slower if you call functions with bool parameters a lot, especially if the compiler is not doing inter-procedural optimizations.
(I'm not sure about all of this. I just started learning x86 assembly 2 months ago, and don't know nearly as much as I appear to know to an untrained eye ).
There are too many things to worry about when it comes the optimization, and many times the only way to know for sure is to try both and compare. In this case, though, I would just choose whichever conveys the logic of the program best (bool in this case), and let the compiler do its job. Modern compilers are VERY smart, and unless you are intimately familiar with your hardware and is a very experienced low-level programmer, chances are you won't beat the compiler at micro-optimizations. You can assist the compiler by making your code as clear and as simple as possible.
Funny you should say that. I remember reading somewhere that you should never use a variable smaller than an int, if space is not a concern, and you are going to use the value for any kind of computation, because the microprocessor will convert the value to an int anyway, and slow you down. Since then I tried looking for that advice by Googling various keywords, and when I didn't find it repeated anywhere, I decided to ignore it. Now, I guess I don't know what to think.
That may be true for some architectures, but I don't think it matters for x86. x86 only demands that memory accessed be aligned (so a 2-bytes access should be on an even address, and 8-bytes access should be on an address that's multiple of 8). It has instructions for working with all different sizes (1, 2, 4, and 8 on 64-bit) directly.
Again, I'm no expert in this, so someone please do correct me if I am wrong.
Unless I'm very much mistaken integer operations are generally the fastest. However, cyberfish is also right that in arrays, smaller elements will be gentler on the cache. So which is faster? I don't think anybody can know without a LOT of calculations - or simply by trying.
Enum is preferred to integers here, irregardless.
Integer operations may be faster than short or char, but for bool, the operations are so simple, that I don't think it likely that there is any slowdown.
Irregardless, Memory is always slower than any CPU computation, so anything that speeds up memory is more significant than a CPU speedup. So yeah, I agree with cyberfish about arrays and containers. For a large collection of bools std::bitset can be considered.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
You know I never considered it on this sort of a level. I'm far from any sort of expert on the low-level workings of a CPU and memory bus architecture and, frankly, the second someone starts talking about bit alignment and memory padding and stack registers my eyes glaze over and I tune out completely (that stuff gives me a headache... I never did understand ASM) so I tend trust that the programmers of my compiler actually know what they're doing and let my compiler do the grunt work.
I was mostly concerned with possible noticible speed differences.... like the kind of speed difference that you'd get from using the built-in rand() functions versus building my own PRNG (or using one from the multitude of PRNG's available).
Anyway, thanks for all the tips. I think I'll stick with a bool array for the time being. Keeps the code readable, immediatly obvious and provides automatic value capping.