Question

I don’t know how to type this in to google, so I’m asking this here.

In programming, do operators take different amounts of time or CPU usage? For example would:

x = y + z

take less amount of time/CPU than:

x = y * z

?

I know it is not noticeable, if at all. Just a curious question.

Also, if you could include as many operators as possible such as +=, -=, *=, and /= along with all normal operators.

Thank you!

Answer 1

There is no master list for all languages, data types, CPUs, and so on, because there is just too much variability.

In some languages, operators are just syntactic sugar for full dynamically-determined type-dispatched function calls, so “a + b” could wind up being a complicated function call that takes minutes, while “a * b” might be a simple function call that takes milliseconds—or vice versa.

In languages that have fixed, compile-time types (including C++ as well as C even though C++ has overloading), you can determine at compile-time what’s going to get invoked, which helps pin things down a lot, but still does not give you a final answer. (See also Dan D and Alex’s answers.)

“Augmenting operators” (+= and so on) are usually just shorthand for assignment-after-expanded-operation. The actual operation takes the same amount of time. In languages with dynamic type dispatch, sometimes you cut off some auxiliary (non-operator) work as well since the augmenting operation need only look up the type of the variable once. With static (compile-time) typing, as long as the compiler is reasonably smart, simple a += b type operations never save anything over a = a + b at runtime, they are just easier to read. More complicated cases, like p->q->r->s += t, can actually save time since (in tricky cases) the p->q->r->s evaluation has to be done repeatedly if it’s written out repeatedly.

As for the underlying CPU operations, there are some rules of thumb, but you have to haul out the appropriate CPU manuals to see which ones apply:

• For integers, addition, subtraction, and logical operations like and/or/xor are never any slower than any other operation
• For integers, multiplication is “harder” than addition, i.e., may be slower than addition etc, but may still be very fast as long as there is sufficient CPU-power dedicated to it; and division may be slower than multiplication, or may still be fast
• For floating point operations, addition and subtraction are “harder” than multiplication and division, so they may be slower (or not, again it depends on how much transistor real estate there is dedicated to the FPU)
• If there is no FPU, floating point is likely slower than integer
• If there is a barrel or funnel shifter, shifts are always fast, but if not, shifts may take longer depending on “how far” the shift goes (e.g., x >> 4 may be slower than x >> 1)
• In modern CPUs, the instruction scheduling @Alex mentioned above may or may not depend on the order of instructions, e.g., it may help to intersperse FPU instructions among integer-unit instructions (or it may not)
• Cache effects (including placement of branches near particular points in cache lines as well as multi-level cache misses, and also TLB misses) can completely swamp the effects of careful instruction scheduling on some CPUs

These kinds of things make writing modern compiler-optimizers pretty tricky. 🙂