Simple Math Optimization Question

Started by
6 comments, last by Jason2Jason 20 years, 9 months ago
Hey, I read a while ago about / operator having more overhead than the * operator. I can''t find the article that explained it well anymore so I''m asking here. I''m write a function thats going to be called many times during the program, so I need every little bit of optimization I can get. I''m dividing a number by 100 like so:

SomeNum/100
 
but I''m thinking would it be faster to do:

SomeNum*0.01
 
The only problem with that is that it would have to use a floating point, would that slow it down? Is there a way with bitshifting to do this? If you know of any good articles that contain clear examples of math optimization, please post your links. I''ll continue to search as well, thanks, -J
Advertisement
For simple math optimizations like this, your compiler is smart enough to figure out the best way to do it. Just don''t worry about it. Google for "premature optimization" if you still feel like it.

Note that in this case, the multiplication method involves an int-to-float conversion (cheap), a floating point division (expensive), and a float-to-int conversion (expensive as all hell). So it would be very, very slow indeed.

How appropriate. You fight like a cow.
multiplication by the inverse is always faster

look at time comparison from that article

in your example you had a integer division which takes around 35.9ns to execute on a 1.1 ghz, on the other end, a float multiplication takes 2ns to execute. So you save 33.9ns! Of course you have to convert your int into float but that sure takes less then 33.9ns!

EDIT: im not even sure if the comp has to convert the int... cuz actually the FPU can handle ints and floats and you can just pass int to assembly float operations and it will work...

[edited by - sross on July 3, 2003 5:06:47 PM]
Stéphane RossGame Gurus Entertainment
quote:Original post by sross
in your example you had a integer division which takes around 35.9ns to execute on a 1.1 ghz, on the other end, a float multiplication takes 2ns to execute. So you save 33.9ns! Of course you have to convert your int into float but that sure takes less then 33.9ns!
And back again. And if you don''t think that takes awhile, you haven''t been programming for long.

quote:EDIT: im not even sure if the comp has to convert the int... cuz actually the FPU can handle ints and floats and you can just pass int to assembly float operations and it will work...

Incorrect. The FPU can only handle floats, except for conversion operators.

Perhaps you''d care to actually try this out? You''ll find that division is about seven times faster, depending on your processor.

How appropriate. You fight like a cow.
quote:
quote:Original post by sross
in your example you had a integer division which takes around 35.9ns to execute on a 1.1 ghz, on the other end, a float multiplication takes 2ns to execute. So you save 33.9ns! Of course you have to convert your int into float but that sure takes less then 33.9ns!


And back again. And if you don't think that takes awhile, you haven't been programming for long.


hmm well the multiplication by the inverse is considered as an optimization trick by Andre Lamothe in his recent book... so i dont see why you would say it aint good...

quote:
Incorrect. The FPU can only handle floats, except for conversion operators.


then why are there FIADD, FIMUL, FIDIV fonctions that only works with ints...

EDIT: doh yep your right... just read in my book the integer refered to by op1 is converted to a real and divided into the stack ( FIDIV op1 )

but suppose the int to float really takes a huge amount of time... cuz yes i dunno how much time it takes to convert an int to a float... but one thing is sure is that you just dont need int... you just need to use float instead... since anyway int and float operations takes about the same time on modern comps (around .1 ns more for float point operation) so if you can save the int to float conversion that way its worth it... my current math engine works only with float and use the multiplication by the inverse everywhere it can and it is quite effective.



[edited by - sross on July 3, 2003 5:28:58 PM]
Stéphane RossGame Gurus Entertainment
7 times faster to divide a?Let us only suggest that things like floating point numbers doesn''t exist(learn ASM) and all we have is bit shifting that you''ll probably noticed that to multiply by the inverse is alot faster if we have to do more than one operations with the same scalar.


"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR
SomeNum/100

is it supposed to be an integer division?
(I assume SomeNum is SomeFloat.)

Anyway, if 100 is a float then someNum*0.01f will be faster since intToFloat is a bit slow. The compiler will probably optimize this. And in this case it''s a good optimization.

...but if you think the compiler is a god then look at this example.

a = float/someFloat;
b = anotherFloat/someFloat;

will be optimized to

num = 1.0f/someFloat;

a = float * num;
b = anotherFloat * num;

Looks great doesn''t it!
...or?
What happens if both float and someFloat are really large numbers?

Answer, the precision will be much less than the original code. This has happend to me once and then you have 2 options. Either turn off the optimization and the code works as you want or use doubles instead. When it comes to optimization, compiler developers seems to ignore how many valid numbers the code gives compared to the ones the compiled file gives.
I switch all teh vars in question to floats, and just now changed the /100 to *0.01f. I guess y compiler allready optimised this since it skipped it saying no relevent changes detected.

Thanks for the help guys, i''ll keep this in mind for the next time i need to do this.

-J

This topic is closed to new replies.

Advertisement