I heard, that division (/) is a very slow operator, and that * is a lot faster. So, my question is, are these rumors true, for floating point variables(float)? I have some performance sensitive code, where objects have their masses, and their accelerations vary according to them. I have to divide, the force affecting an object, by the object's mass, to get the acceleration. Should I store 1/mass, and then multiply by the mass, to gain performance?

Thanks.

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.

Thank you, and the idea of 1/mass, is great, I planned to hold another integer variable, "is_static" for this purpose.

But, after looking at the code, and thinking about the division, I found out that, I also have a variable similar to fps (frames per second..) by which I divide a lot of things every frame, to guarantee the picture motion not to be fps dependent. So, should I replace it with 1/(it)?

Thanks.

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.

I'm going to get different results then, I suppose..

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.

I'm doing a "model", of some physical phenomenon, so actually the performance limits the amount of objects can be processed at a time, and the complexity is n*m.

Thanks.

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.

Oh, yes.

Yes, definately. Avoid divisions as much as you can.

Why do you need to multiply by the mass again? If you're dividing it out first and then multiply by it again, the best thing to do is not to do either.

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?

AFAIK, converting int <-> float is slower than any mathematical operator.

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 */

Guys, the original question was about floats specifically.

For integers, I think the difference between multiplication and division (in terms of speed) is less severe, if I recall correctly. Yes, bitshifts are faster for integer power-of-two divisions (or multiplications for that matter), but the compiler should catch those anyway and do the optimisation for you.

Oh, minor detail: don't mix float and integer arithmetic if you can avoid it. It'll be slower than plain floats becaused you get the extra cost of promoting the integer to a float.

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.

Well, I mean multiply by the coefficient that I get..

Thanks, but I'm quite sure that if mass, is a float- in both cases I'm going to get float as a result.

And, yes I'm using only floats..

And, by the way, your posts have awakened another question:

A: 100/2
B: 100*0.5

What is faster?

I have no idea how to enable it in VS8 though What is this option's name?

Thanks, to everybody.

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.

Your advice is valid and true. But wouldn't the compiler cast the int to a float at compile-time?

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

There is no such mode in the free version. AFAIK it is only availiable in the enterprise version. Get a real compiler, like GCC

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.

project > properties > c++ > code generation > float point model

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.. ?

I'm not 100% sure but I think Professional edition doesn't have profiler either. Then again I doubt you need to worry about performance that soon.

You could manually measure the time by using some high-precision counters (allegro timers are not one of those). Perhaps googling for RDTSC can help you. Though under Windows you also have some other functions whose name I can't remember exactly. It was something like GetXXXFrequency and GetXXXCounter or something like that

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()

Perhaps when your code consists of awfully lot of templates. If you don't have too much of them GCC is one of the best optimizing compilers out there being only a little behind ICC, at least for heavy number crunching. When we compare 64bit compiling then GCC can even beat ICC leaving MSVC far behind.

Are you sure? I somehow remember using it on my older P4 dualcore and it worked fine. Perhaps it is some kind of Linux thing that makes it work though.

Ah, that was what it was called

there is a discussion about it on MSDN somewhere. laptops under SpeedStep conditions will give varying RTDSC results.. speedstep can occur quite often.

RTDSC is a CPU instruction, from which CPU will it obtain the result?

Yes, speedstep will screw up things. Still RDTSC is the counter with the least amount of overhead compared to other methods (IIRC windows *PerformanceCounter functions were around 100x slower).

unless your cores run at different frequency they should have equal counter value. IIRC it started at zero on bootup. I know AMD offered a patch to Windows that fixes it (nothing for Linux, guess it works there). Though I'm not sure if it also helps with speedstep.

Per wiki, and I'm inclined to agree:

In addition, RDTSC is a ring 0 (kernel mode) instruction so shouldn't be available to your code anyway. Assuming your OS is well written, using RDTSC should cause your program to crash.

So, no benchmarking routines available for newbie programmers?

it doesn't matter if QueryPerformanceCounter() is 100x slower... as long as its consistant.. real-clock cycles is irrelevant, your only ever comparing the results against another set of results taken by the same clock. the two result sets are compared against each other. whats important is the resolution is high enough to actually see when there is a difference.. hence why allegro's timers are in-adequete. (spelled that one wrong!!)

[edit] you should use QueryPerformanceCounter() but if your running on a molti-core machine, lock your process to 1 CPU, using SetProcessMask()

With multisocket CPUs I agree that it isn't reliable, at least not without binding your program to specific CPU.
Also I'm quite sure that RDTSC is not ring 0 instruction (why should it be?) as I've been able to use it without problems in XP and Linux without having administrator privileges.

I'm not saying that RDTSC is the one best way to measure performance. I just say that it is one of the easiest to use*, it is supported on pretty much every x86 CPU and it doesn't have too much overhead. Of course to be able to use it you must do all sorts of other tricks like disable power saving functions and lock your program to run on one CPU core.

In later CPUs there exist a new instruction that is similar to RDTSC but it increases at constant rate and shouldn't get messed up with multisocket/core machines.

[edit]

For as long as QPC itself doesn't take comparable amount of time to execute than the piece of code you are measuring it can be used quite well.

its not a Ring0 anything, its an actaul CPU instruction, just like all the other CPU instructions your code runs, it does require ASM code, because C has no equivalent.

"For as long as QPC itself doesn't take comparable amount of time to execute than the piece of code you are measuring"

huh? the time QPC takes compared with the code is irrelevant too. if QPC takes 1second to execute, and your code takes 1ns, the result will be 1.000000001 sec
if your 2nd test code takes 2ns, the result will be 1.00000002 sec.

from that you can calcuate that the two peices of code differ by 1ns.

result.

Fixed!

Not exactly. During execution of that instruction all sorts of "fun" things can happen like context switch. E.g one time it might execute in a hundred ns, next time a few thousand.

You obviously don't know what you're talking about, so I don't intend to engage in a full discussion with you. This link might help, but I doubt you'll bother reading or comprehending it.

If I may ask where did you read that RDTSC is a ring 0 instruction? This is the first time I hear about it.

Oh, I could just be a million years out of date. RDTSC was definitely a ring 0 instruction on the original Pentium (source, first one I could find), nothing immediately suggests it still is. And I can't really find time for a thorough search right now. What do Intel say?

The RDTSC is read-only in Winduhs, you can read or write to it in DOS (ring 0), I've read it in Linux but didn't try writing to it. Probably Linux & Windows set some permissions or something, I doubt it's trapping it with an exception.

And division will always be slower than multiplication, the trial divisor stuff (or equivalent brute force) and dependency on what the previous subtraction left makes it hard. Theoretically a multiplication could be split up among multiple CPUs.

Actually RDTSC is a machine instruction that copies a number from deep within CPU to regular registers but you probably already know that
Are you talking about some other instruction that writes to the place where RDTSC holds its counter value?

Actually there's a WDTSC or something to write to the time stamp counter, that's what I meant I used in DOS. The earliest Plentiums had to use MOV's with eax, ecx and some weird mmr register or something. It was ten years ago, I'm a little hazy on it.

Thomas, dont know what I'm talking about huh?
yes I did read the article, didn't see any mention of RTDSC.

No, I'd say you don't know what you're talking about - or at least you don't know what ``Ring 0'' means.
That's not a bad thing per se, we all need to learn things at some point.

Ring 0

Right. I've grabbed the official intel x86 documentation, and found this on page 644:

So RDTSC can be ring 0 if the OS wants it to be. The availability of RDTSC therefore technically depends on your CPU — though I think everything P2 equivalent and upwards has it (?) so that's probably not much of a concern — and your operating system. So it may not be smart to advise it as a general solution, and it definitely isn't a good idea to use it in shipping code unless you can find a guarantee as to its availability from your OS manufacturer.

How does this work? Once you set the TSD flag it cannot be unset? So basically the program that first runs ( the OS ) can set it and have Ring 0 privileges. Is this how it works?

Without reading the documentation I assume that it is set by the CPU itself during bootup (before any BIOS stuff gets shown)

Hoho, a pentium 4 does not have 2 core, it has hyperthreading which is quite different, which can explain why you had consistent result with RTDSC

EDIT: correction, some have both hyperthreading and dual core.

... and I've had both