Hello Matias, thanks for the reply.

I was looking for some info specific about what is called branching, it is still not clear to me :

if i use only the "if", and not the brackets after, is it still branching ?

and what if i only use the brackets like this, without the if :

{

// code here

}

does that also count as branching ?

greetings

Branching is when the code executed next is chosen based on a condition. This includes of course if statements but also loops, since they need to decide whether to run the loop body one more time or stop looping based on the condition.

Also, things being functions/macros does not make them slow, because any modern compiler will be able to inline it if the function itself is simple. Eg. with the fmod, which is a couple of arithmetic operations, it is very likely that the same machine code is produced when you write the math inline yourself or use the function.

Warning: the following may come across as a little harsh. I don't mean to offend, but I think you might benefit from this advice (some of which has been offered in the posts above).

Maybe you all dont worry much about CPU intensivity as i do

You're worrying about it much more than you should, and unless you're using a profiler to measure alternatives there's a good chance you're just wasting your time or even actually making things slower/less efficient with your attempts to optimise.

Modern compilers are very complicated and able to do a lot of very clever optimisations on your code; very very talented programmers have put years of work into making them do this very effectively. If one way of writing code is obviously inferior to another it's likely your compiler will make the change for you. It takes a lot of experience to out-think your compiler and achieve better performance.

You should instead be more focused on writing code that is clear (i.e. easily read and understood) and correct (does what you want) and then only worrying about optimisation if you can actually demonstrate that your program isn't fast enough, at which point you would start to optimise the parts of your program your profiler shows to be the slowest rather than making guesses or trying to micro-optimise small things like you're worrying about in this topic.

By worrying about these low level details without actually measuring performance properly you're almost certainly simply making your code more harder to read, more complicated (and therefore more prone to bugs), and not actually gaining any performance over simply using the most obvious code and allowing your compiler to do it's work. The very question you started this topic with is an obvious example -- it's likely that neither or your alternatives would perform better than the other once the optimising compiler has done it's job, but one version has a precision problem that will result in incorrect behaviour if not handled -- you're worrying needlessly about performance but hadn't noticed that one version of your program could be buggy.

Optimisation is absolutely an important and worthwhile topic, but you're simply not going about it the right way with your current approach. Learn about proper optimisation and take advantage of the tools (profilers, optimising compilers, etc.) that are available to help you rather than "voo-doo/superstitious coding" where you avoid functions you think might be performance bottlenecks.

I hope that's helpful!

if i use only the "if", and not the brackets after, is it still branching ?

and what if i only use the brackets like this, without the if :

{

// code here

}

does that also count as branching ?

greetings

If you are asking this, you are in absolutely no position to be worrying about whether branching is faster than a math operation or not. You need a really thorough understanding of what is going on under the hood of your compiler if you want micro-optimisations to be anything other than a total waste of time.

Let me tell like this : i have tested all this, get the time, repeat 1000 times, then get the time again.

Test showed me the simplest if was faster then functions, it was a while ago, i should test it again on my new pc maybe ?

Can a i7 be faster with sin() instead of a lookuptable? , and maybe a Celeron ( which is my current game development pc with onboard graphics ) cant ?

If you are asking this, you are in absolutely no position to be worrying about whether branching is faster than a math operation or not. You need a really thorough understanding of what is going on under the hood of your compiler if you want micro-optimisations to be anything other than a total waste of time.

If i worry about optimalization,i must be in some position, right ?

I have learned programming not on school, i also dont know how to use a debugger.

Is that a problem ?, i thought questions are never dumb, i skip learning everything that is not needed to get result, if i need something i can Always ask it.

But if you defending your own business, ofcourse you dont wanto tell the competition how to get your games optimized,

i,m telling you : games are not playable with functions like sin() and cos() and sqrtf() ( i still need to get some fast sqrtf function by the way ).

Note : i,m Always having 1000 bullets and explosions in screen, so maybe this does not count for your i7 pc with 2 bullet and 1 explosion ?

greetings

Hi there, seems very cpu intensive + i have no clue about complex, and why use exp, the rotation is linear right ? ( it rotates good in screen so i bet );

I mean : i just have a wheel or circlesaw rotating.

float rot = 0.0;

// in loop

{

rot += fElapsedtime;

// now i wanto know if its better to use this :

if( rot > Pi )rot -= Pi;

// otherwise the float rot will be increasing unlimited, i dont know how if affects the cpu;

}

So my question is :

What is more CPU intensive, having the if, or having the huge float numbers ?

Rather than worry about which is fastest, worry about which will give you the correct result, (or atleast a correct enough result).

Trig functions on x86 are only accurate in the -PI to PI range (beyond that the results start to drift off and the error gets worse the further away from that range you get), a float also normally only has 32 bits of accuracy, making small increments to a huge floating point number will not give you the expected result, restricting the scale of your rotation value is necessary to ensure a sane behaviour, (you may not need to restrict it to the -PI to PI range, but you have to restrict it)

Languages such as Java will restrict arguments passed to trig functions for you (but does so with higher than native precision argument reduction which is pretty darn slow so with Java on x86 you absolutely should restrict it to the -PI to PI range).

If you are on an architecture without a FPU or with a fairly weak FPU you might benefit from ditching trig functions completely and instead use lookup tables(best to use integers for your rotations then, just remember that it will likely be slower than trig functions on a modern CPU due to cache misses (reading from RAM is very slow) or fast approximation functions (depending on what precision you need), on newer x86 you can also use SSE to implement very fast high precision trig functions (using exponents or taylor series)

Thanks Simon, valuable information.

@ jbadams : Is Microsoft Visual Studio Professional 2005 considered a modern compiler ? thanks.

You should instead be more focused on writing code that is clear (i.e. easily read and understood) and correct (does what you want) and then only worrying about optimisation if you can actually demonstrate that your program isn't fast enough, at which point you would start to optimise the parts of your program your profiler shows to be the slowest rather than making guesses or trying to micro-optimise small things like you're worrying about in this topic.

By worrying about these low level details without actually measuring performance properly you're almost certainly simply making your code more harder to read, more complicated (and therefore more prone to bugs), and not actually gaining any performance over simply using the most obvious code and allowing your compiler to do it's work. The very question you started this topic with is an obvious example -- it's likely that neither or your alternatives would perform better than the other once the optimising compiler has done it's job, but one version has a precision problem that will result in incorrect behaviour if not handled -- you're worrying needlessly about performance but hadn't noticed that one version of your program could be buggy.

Hi, i also have comments above the code, wich is the slow readable code,

ofcourse i know the importance of readable code, especially with a project this big, i dont know the line count, alot of files for sure,

more then fits the screen!

Ok, i will make a test, and test it on my Celeron and a i7, let see, interesting.