Speed of C++ operators/ simple math

Question

I'm working on a physics engine and feel it would help having a better understanding of the speed and performance effects of performing many simple or complex math operations.

1. A large part of a physics engine is weeding out the unnecessary computations, but at what point are the computations small enough that a comparative checks aren't necessary?

   • eg: Testing if two line segments intersect. Should there be check on if they're near each other before just going straight into the simple math, or would the extra operation slow down the process in the long run?

2. How much time do different mathematical calculations take

   • eg: (3+8) vs (5x4) vs (log(8)) etc.

3. How much time do inequality checks take?

   • eg: >, <, =

Answer 1

1. You'll have to do profiling.

2. Basic operations, like additions or multiplications should only take one asm instructions.

   EDIT: As per the comments, although taking one asm instruction, multiplications can expand to microinstructions.

   Logarithms take longer.

3. Also one asm instruction.

Unless you profile your code, there's no way to tell where your bottlenecks are.

Unless you call math operations millions of times (and probably even if you do), a good choice of algorithms or some other high-level optimization will results in a bigger speed gain than optimizing the small stuff.

You should write code that is easy to read and easy to modify, and only if you're not satisfied with the performance then, start optimizing - first high-level, and only afterwards low-level.

You might also want to try dynamic programming or caching.

Answer 2

Well, this depends on your hardware. Very nice tables with instruction latency are http://www.agner.org/optimize/instruction_tables.pdf

1. it depends on the code a lot. Also don't forget it doesn't depend only on computations, but how well the comparison results can be predicted.

2. Generally addition/subtraction is very fast, multiplication of floats is a bit slower. Float division is rather slow (if you need to divide by a constant c, it's often better to precompute 1/c and multiply by it). The library functions are usually (I'd dare to say always) slower than simple operators, unless the compiler decides to use SSE. For example sqrt() and 1/sqrt() can be computed using one SSE instruction.

3. From about one cycle to several dozens of cycles. The current processors does the prediction on conditions. If the prediction is right right, it will be fast. However, if the prediction is wrong, the processor has to throw away all the preloaded instructions (IIRC Sandy Bridge preloads up to 30 instructions) and start processing new instructions.

That means if you have a code, where a condition is met most of the time, it will be fast. Similarly if you have code where the condition is not met most the time, it will be fast. Simple alternating conditions (TFTFTF…) are usually fast too.