It's not really that simple any more. Most processors have multiple arithmetic units, and they schedule your instructions to try and use as many of those as possible at once. Nowadays most arithmetic units that can do both multiply and divide do them in the same amount of time, but some CPUs have units that can't do both. As an example, the G5 which Apple used prior to switching to Intel had two arithmetic units, one could do divide and multiply, the other only multiply. The processor before, the G4, had four arithmetic units, of which three could only do addition and subtraction and the fourth could do divide and multiply.

To be honest, I don't think storing 1/mass is going to make any tangible difference to your processing. But you might consider storing 1/mass anyway, because it means you can conceptually store objects with 'infinite' mass, i.e. objects that cannot be moved. Which are quite common in games.

if you are going to be dividing by 1/mass in a lot of places it is a really good idea to cache 1/mass and multiply instead.

1. premature optimzation. your sensitive code probably amounts to .001% of your programs runtime. dont get your panties in a bunch over code that takes .001% of runtime.

2. division is slower than multiply. sometimes (and its worth timing this to be sure).. you can multiply by a factor, then >> to achieve the same division, but at higher speed. it really depends on how many items you have to divide.

3. trust no one. Benchmark your results, half of everything you hear is rumour or based on limitations of old hardware.

There are compiler options to compile in profile mode. It will add extra instructions in the executable that count how many time each function is used, how much time is spent inside, etc. After a good run, you can analyze the report to see which functions are worth your time.

Um, isn't multiplication faster because you don't always deal with floats, i mean, would this 100*0.5 be faster than 100/2?

I remember using bit shift for power of two multiplication/division on integers.

int a = 200 , b = 50 , result = 0 ;

result = ( a >> 1 ) + ( b << 1 ) ;
/* result = ( a / 2)  + ( b * 2 ) */

printf( "%d\n" , result ); /* this would output 200 */

By the way, in the C sources, I'm not sure the compiler optimizes implicit conversions on litterals, so be sure to write float litterals : 1.0 / mass, not 1 / mass.

You don't seem to believe my advice that unnecessary casting ints to floats will make your "optimization" slower than the original.

For a C compiler, A produces an integer, while B takes 200% time and produces a float.

Profiling: No idea, the Allegro manual only gives precise indications for gcc compilers.

Oh, ok.. But as aj5555 said, only what worth optimization should be optimized, and mass / mass_coefficient, are only initialized once.

If you put integer litterals in float computations, you'll grow carefree and a seemingly innocent "new_size = 75/100 * old_size" will devour you.

I'm using Microsoft Visual Studio 2005 Professional Edition, not like I'm a professional, but anyways.

I understand.. but in such cases if I remember, I do it 75.0/100, or cast the 100 in to float.

Hmm, how does it work though, if I choose let's say fast. And, does it affect double? Thanks for the tip though.

So, in visual studio, no such option, to see how many time does the program spend in each of the functions.. ?

as far as GCC being a real compiler... MSVC produces faster code (on average)... GCC's strength is in its warning/error, and standards compliance. MSVC is more forgiving (which leads noobs to beleive they are doing things correctly). however as far as code generation goes, you'd have a tough time saying which compiler is better.

type568, float point model is a hint to the compiler about how to handle rounding situations and how to cut-corners when int-float-int conversions are done, if your not uber critical of the results, use fast. you can always select this option on a file by file basis.

do NOT use RDTSC on multi-core machines, your results will not be consistant.
on win32 use QueryPerformanceCounter()