Speed Question

Yip! As far as I know, always try to multiply with a fraction than to devide with an integer-float.

EDIT: Well this only works faster if you are working with floating point numbers! Don't do it with an integer because you'll suffer convertion overhead.

example:

int a = b * 0.5; // NO!
int a = b >> 1; // OK
int a = b / 2; // OK

float a = b * 0.5f; // Yes, no matter what b is!

That depends on the types (programming languages may introduce expensive implicit casts), if we are only talking floating point, on the x87 FPU, then multiplication will always be faster.

Assuming C/C++, any modern optimising compiler should generate exactly the same assembly code from both. You're probably optimising prematurely. Look for things that will give you a real speed boost, like using the right algorithms (i.e. quicksort vs bubblesort), first and don't worry about the low-level issues until and unless a profiler indicates they are a problem.

Σnigma

Quote:

Original post by Enigma Assuming C/C++, any modern optimising compiler should generate exactly the same assembly code from both.

Nope, it won't.
In FP math, a * 1/b != a / b, so the compiler will *not* by default optimize such things.

It won't even optimize an expression like this:
e = a + b + c + d
into this:
e = (a + b) + (c + d)

For the same reason. It yields a (slightly) different result, and the compiler has no way to determine whether you cared about those last few digits, so it has to be cautious.

But yes, you probably are optimising prematurely, no doubt about that.

OK, I should have been clearer. In the specific case of 4 and 0.25 a modern optimising compiler will and does generate identical assembly code (always an fmul opcode). I tested this under Borland, GCC and VC++. Presumably this is because 0.25 and 4 are both exactly representable as double values and therefore it is provable that the optimisation does not affect the result. For values which are not exactly representable most compilers will not perform this optimisation.

Σnigma

If you are attempting to improve FP performance many compilers offer the ability to turn off IEEE floating point, which will allow optimizations that slightly impact accuracy. I think the flags are GCC -ffast-math, VC /fp:fast.

But if you get to something like this:

float a = d / e;
float b = c / e;

Then it is better to:

float f = 1.0f / e;
float a = d * e;
float b = c * e;

Well only if you have to divide with 'e' more than once!