gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > is this a good optimization

#22444 - ProblemBaby - Mon Jun 21, 2004 1:04 pm

in my main game loop
I call a lot of differnt functions
like get input, handle different stuff and so on
BUT they are called only once per frame
is it smart to declare those functions as inline then?

if not, why??

#22447 - poslundc - Mon Jun 21, 2004 2:02 pm

No, it's not smart, for several reasons:

- Inline functions are generally only useful for very short blocks of code only - usually less than five lines or so - that are called more than once, where it is more efficient to have the code copied in directly every time it is needed rather than branching to and returning from a subroutine.

- Code that is only called once per frame will not be made any more efficient by being made inline. It may, however, result in a much larger and more wasteful stack, and it may be much harder to debug.

- Premature optimization is the root of all evil. Get your program working first, and then if you need to squeeze more speed out of it you can profile and optimize your code. I guarantee you won't save anything noticeable by inlining functions called once per frame.

Dan.

#22454 - ProblemBaby - Mon Jun 21, 2004 8:49 pm

Aha I thought inline worked like a macro!
but is it good if Ive a quite small function
that should be called through a for-loop a couple of times??

Then i have another question about optimization.
Is it smart to have a LUT for Division?
I use it very much in collision detection and to find screen-positions!
I would need about divisions for -32/32 FIXED
thats 64*256 = 16384 * sizeof(s32)
Thats quite much! but do it make it much faster?
I need speed!

#22455 - poslundc - Mon Jun 21, 2004 9:08 pm

I don't know how you figured on your calculations for the size of your LUT, but if you leave it in ROM then 64K is not a big deal, and it would only consume a quarter of your EWRAM, which depending on your application's needs may be worthwhile. And a reciprocal LUT in EWRAM is simply the fastest way to divide by a non-constant amount.

Dan.

#22456 - sajiimori - Mon Jun 21, 2004 9:25 pm

Quote:

but is it good if Ive a quite small function
that should be called through a for-loop a couple of times??

If it's really only a "couple", then it still won't be significant. Seriously, forget about inlining until you've identified your bottlenecks.

#22457 - poslundc - Mon Jun 21, 2004 9:42 pm

Um, yeah. Listen to saji. Inlining is provided mainly to accomodate those rare situations where the need for form and readability comes into conflict with having sensible, efficient code.

In other words, it is only to allow programmers to code in a style that is modular and encapsulated without it being recklessly inefficient with the calling of functions. An example would be calling a function every single time you need to take the absolute value of a number. You want to (and should) use a function call rather than having "if" statements all over the place, but the overhead of a function call would be extremely wasteful in this circumstance, so an inline function provides the form without the overhead.

Don't think you can go through your code adding "inline" everywhere - or even anywhere - to improve its speed. It is a bit of a surgical tool, and needs to be applied delicately.

Dan.

#22458 - sajiimori - Mon Jun 21, 2004 10:28 pm

A couple additons:

The 'inline' keyword already means very little (gcc -O3 does auto-inlining), and it will only mean less as compilers get smarter. Some of the more advanced compilers are already at the stage where you only specify how important each factor is (code size, execution speed, safety), and it does appropriate optimizations based on your choices.

#22469 - NoMis - Tue Jun 22, 2004 8:41 am

Another thing about inlining. The inline keyword just tells the compiler that you preferre this function as inline but its up to the compiler to do it

" ... The inline keyword tells the compiler that inline expansion is preferred. However, the compiler can create a separate instance of the function (instantiate) and create standard calling linkages instead of inserting the code inline.

Things that usually make the compiler ignore your request are: using loops in the inline function, calling other inline functions from within the function, and recursion. ... "

"Performance Programming applied to c++"
http://www.gamedev.net/reference/articles/article1139.asp

#22494 - jma - Wed Jun 23, 2004 2:25 am

Another great reason to use inlining is if you have code that will compile away and you want the compiler or optimizer to catch it. For example, check the following:

Code:
inline void set_x(int new_x) {
  ASSERT(new_x >= 0 && new_x < 100);
  global_x = new_x;
}


This is a wonderful place and reason to use inlining. The ASSERT() will not be compiled into release code, but you don't want to use it over and over again whenever changing a variable's value, so you bust out a function that will do it for you. But calling a function that does nothing but set one value is a waste of processor -- so inline it.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org