Is it any good to use binary arithmetic in a C++ code like "C style"?

Question

I like the fact that the C language lets you use binary arithmetic in an explicit way in your code, sometimes the use of the binary arithmetic can also give you a little edge in terms of performance; but since I started studying C++ i can't really tell how much i have seen the explicit use of something like that in a C++ code, something like a pointer to pointer structure or an instruction for jumping to a specific index value through the binary arithmetic.

Is the binary arithmetic still important and relevant in the C++ world? How i can optimize my arithmetic and/or an access to a specific index? What about the C++ and the way in which the bits are arranged according to the standard?

... or i have taken a look at the wrong coding conventions ... ?

Answer 1

In short: No, it is not any good to use "binary arithmetic"(in sense the question asks it) or "C style" in C++.

What makes you believe bitwise arithmetic would be any faster really? You can throw your bitwise operations all over the code, but what would make it any faster?

The thing is, almost whatever trivial thing you're trying to solve, can be solved easier by the standard high-level features(including the standard library, STL and STL algorithms). In some specific cases you might indeed want to switch the individual bits, for example when working with bitmasks. Or storing very compact data, for example when writing a compression algorithm, a dense file format or working for example with embedded systems.

If you are concerned with performance, always write a simple and trivial algorithm first. Just make it work. Then, measure the time your algorithm takes with typical input. Now, if you at this point feel that it is too slow, only then you can try optimizing it by hand with these "bitwise arithmetic" tricks. And after done, measure if your code is any faster. The chances are that it is not, unless you really know what you are doing in that specific situation/case.

Frankly, the best way to understand about this kind of low-level constructs which deal with performance is to study assembly language. It really makes you realize that no, writing some bit-manipulating wizzcode is not any faster than using that sort(begin(v),end(v)). Just because you operate at low level doesn't mean you operate fast. In general, Algorithms are more important than implementation details!

Basically whatever the "C style" means, please, stay away from it when writing C++. They are two completely different languages. Don't mix them.

Bjarne Stroustrup gave a great talk about C++ style in Microsoft's GoingNative 2012 conference this February, please take a look: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style

Especially the parts between around 10 and 15 minutes are great, when he talks about old C-style code compared to modern C++ style.

Answer 2

for example the shift operator << or >>, which is a quick way to calculate "something times 2" or "something divided by 2"

Whether you're working in C or C++, write what you mean. Write foo = foo * 2; or foo *= 2; if that's what you mean, not foo = foo << 1;. Let the compiler take care of finding the fastest instruction to use and don't confuse the people who have to read your code with unnecessary hand optimization.

Answer 3

Follow these steps:

1. Write the code as simple and clear as possible.
2. Turn on all compiler optimizations.

3. Consider whether you have sufficient knowledge about the specific target CPU and its instruction set (assembler). If not, then you will probably have a hard time to do any manual optimizations and should probably not attempt it, as you will likely just end up obfuscating the code for no gain. Also note that manual optimization is only necessary if your compiler has poor support for the specific target platform. As an alternative, you could try another compiler.

4. Identify performance bottlenecks. How to find them depends on the target system. In "high-level" programs such as desktop programming, you benchmark your code through specific tools designed for that purpose, or through OS API functions. On "low-level" programs such as embedded systems, you typically use an oscilloscope to measure realtime performance. On any program, you can disassemble the code and see what the compiler actually came up with.

5. If there are no bottlenecks that affects your program's performance, you don't need to do a thing and you can stop reading here.
6. If there are bottlenecks that have impact on your program, you may need to perform manual optimization.
7. How do manual optimizations depends on the target CPU, there is no universal trick. Common things to look for are: floating point arithmetic, alignment, integer sizes, division, branch prediction & instruction cache handling, use of needlessly complex library functions... and so on.

Answer 4

It depends on what sort of C++ code you're writing. The lower you are the more relevant it becomes. The problem with these types of questions is that everyone can only rely on their own experience and so if someone has never had to do this sort of thing they can't see why someone else might need to do it.

Here's Joel's 'Five Worlds' article

Answer 5

I make use of binary arithmetic in virtually ALL computer languages I've programmed with. For example, take the addition operator +:

int sum = x + y; // compiler probably implements this as binary arithmetic!

I would find it hard to program in a language that did not support arithmetic, and I would find it hard to believe that arithmetic operations were not implemented by your compiler/interpreter using binary arithmetic (such as using base-10 arithmetic).

http://en.wikipedia.org/wiki/Arithmetic#Arithmetic_operations

http://www.binarymath.info/

http://www.swarthmore.edu/NatSci/echeeve1/Ref/BinaryMath/BinaryMath.html

TL;DR: Use the right terminology (bitwise ≠ binary), else you get pendatic answers like this.

Answer 6

Binary arithmetic is bound to the implementation. You must be careful about implementation details such as endianness. Therefore, using binary operators isn't automatically faster than using elementary operators. Often, the compiler will perform more relevant optimizations, and a natural code can be better for performance as well as easier to read for both the compiler and the programmer.

Of course, there are some cases (such as Base64 encoding), where you must use those operators. But optimizing code with binary operators should be the last optimization, coming after perfecting your algorithms. For personal programming, some pretty tricks (like this) may be faster, but with serious programming, readability should come first.

And, like zxcdw said, C and C++ are both very different languages. C++ has more high-level libraries, so binary tricks are less famous.

Answer 7

No, there is no use of binary arithmetic in C++, except one "tiny" detail: the C++ standard defines the language semantics in terms of a binary abstract virtual machine that must use either 1st complement, 2nd complement or sign-magnitude integer representation.

Answer 8

As many have mentioned already, be aware — do not to prematurely optimize things. But when you find CPU-bound code that is a bottle neck, one of the best ways to understand which of your alternate implementations would be better, using Clang C/C++ -> LLVM IR is a great idea. If you're more comfortable in a web browser, try http://llvm.org/demo/.

The IR (Intermediate Representation) generated by Clang and LLVM are virtual machine instructions. You can for instance write the same algorithm/arithmetic function in "C style" and "C++ style" (I'm guessing "STL-style"?) and compare the IR generated by the compiler. Even if your end-product compiler isn't based on LLVM, the IR code will be representative of what code is actually generated and compiled. Beyond IR there is only hardware optimizations (like how landing pads from conditional branches are implemented). LLVM can produce target machine assembly, if you think it would make you wiser (but I wouldn't recommend going beyond IR).

Answer 9

Sometimes several flags are crammed into a single byte to save space. Sometimes it's premature, other times critical.

Microsoft SQL Server will store multiple columns of data type "bit" in the same byte. In this case it's not a premature optimization. You save 2 to 8 times the disk space, for 2 to 8 bit columns (this is a big deal). You get faster searches as well (very big deal). It's also more likely you will be able to cache a set of data in memory. This is perfect. Since there is no benefit in indexing binary data, you might as well pack the bits together. And the bitwise nature is not exposed to client programmers so everyone is happy.

The windows API crams several options per byte. You manipulate the display options with bitwise operations. I would say this one was premature. It also made many people give up on windows programming. But the programmers who wrote the API came from the old days when space was severely limited. At the time it may have been a good idea to design an API around bitwise manipulation.

Client/server video games love to pack multiple flags in a byte. For example, on the server the game calculates your damage. It will send back the display data to the client, with several flags like if it was a critical hit, if it killed the enemy, etc. The display would then process with bitwise operations. This is debatable whether it's premature or not. But I would lean towards saying less is more when pushing data over a network.