Why so many 'inline' ? | Bitcointalksearch.org

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: xf2_org on May 17, 2011, 05:12:07 PM

Quote from: realnowhereman on May 17, 2011, 04:36:56 PM

inlining is not a universally "bad idea", it certainly won't decrease performance. It might significantly increase object size.

Incorrect. Increasing code size decreases cache hit rate, decreasing performance.

Not always. It depends on whether the code fit in the cache in the first place. Or whether it no longer fits with the inlining. The corollary: decreasing code size certainly doesn't always increase performance.

Quote

Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.

This is just silly. If this occurs, there is a bug in your build system.

No serious programmer worries about this.

Include files aren't always properly declared as dependencies in makefiles. I can tell you from firsthand that bugs do happen because of this. A bug in your build file is still a bug. This isn't an argument against inlining though, just a reason to be careful.

Quote

Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit. 'inline' is utterly unnecessary to make the function be inlined.

These two statements don't match up. If you want to "make" (force) the function be inlined, then you obviously do not wish to leave that decision to the compiler.

You can specify the inline keyword, but the compiler won't necessarily listen to you. Some compilers to have special pragmas to force inlining, but they are not a part of the C++ standard.

[/list]

Jim Hyslop

member

Activity: 98

Merit: 20

Quote from: realnowhereman on May 17, 2011, 04:36:56 PM

Some points about 'inline'.

inline on a virtual member is ignored. It's impossible to have an inline virtual.

If the compiler can determine the dynamic type of an object at compile time, then it most certainly can omit virtual lookup, and either call the function directly or unroll it inline if it so chooses.

Consider this code:

Code:

class base
{
public:
   virtual void SomeFunction()
   {
   cout << "In base::SomeFunction" << endl;
   }
};

class derived : public base
{
public:
   virtual void SomeFunction()
   {
   cout << "In derived::SomeFunction" << endl;
   }
};

void f()
{
   derived d;
   d.SomeFunction();
}

The compiler can optimize f() any way it sees fit. In fact, it could compile the code as if you had written:

Code:

void f()
{
cout << "In derived::SomeFunction" << endl;
}

since there is no observable difference between that and what you wrote.

Edit: minor edit to clean up mis-matched 'list' tags

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

My rule of thumb is "never inline methods more than 1 line long."

Unless you're doing something super performance-critical, in which case my rule of thumb is "don't change anything until after you've written a realistic benchmark."

But I'm an old-fashioned C++ coder, kids these days seem to want to put all the code in .hpp files.

goatpig

legendary

Activity: 3766

Merit: 1364

Armory Developer

Quote from: xf2_org on May 17, 2011, 05:12:07 PM

Incorrect. Increasing code size decreases cache hit rate, decreasing performance.

On the other hand inlining in a heavy duty loop will limit code jumps and thus pipeline flushing.

xf2_org

member

Activity: 98

Merit: 13

Quote from: realnowhereman on May 17, 2011, 04:36:56 PM

inlining is not a universally "bad idea", it certainly won't decrease performance. It might significantly increase object size.

Incorrect. Increasing code size decreases cache hit rate, decreasing performance.

Quote

Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.

This is just silly. If this occurs, there is a bug in your build system.

No serious programmer worries about this.

Quote

Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit. 'inline' is utterly unnecessary to make the function be inlined.

These two statements don't match up. If you want to "make" (force) the function be inlined, then you obviously do not wish to leave that decision to the compiler.

realnowhereman

hero member

Activity: 504

Merit: 502

Some points about 'inline'.

inlining is not a universally "bad idea", it certainly won't decrease performance. It might significantly increase object size.
It isn't the case that the "inline" keyword is used to tell the compiler to inline code (bizarrely).
It's use is mandatory when it is needed, and a noop when it is not.
It is used to allow you to put member function definitions outside the class declaration in header files that are included from multiple locations. If you do not include it, then the second module that includes it will generate a linker error as it finds multiple definitions for the same function.

Code:

class SomeClass {
void someInline( int y ) { x = y; }
int x;
};

is exactly the same as

Code:

class SomeClass {
void someInline( int );
int x;
};

inline void SomeClass::someInline( int y )
{
x = y;
}

inline on a virtual member is ignored. It's impossible to have an inline virtual.
inline in the module and not the header will either give linker errors (when other modules don't find the exported symbol, or be ignored.
Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.
Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit. 'inline' is utterly unnecessary to make the function be inlined.

HTH.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: sandos on May 17, 2011, 08:11:30 AM

Well, I thought modern compilers just took that as a hint, and they don't always respect it. I could be wrong though.

Indeed, a modern compiler will choose to inline when it makes sense, no matter whether the developer provides a hint or not (this is especially true with whole-program optimisation).

Nesetalis

sr. member

Activity: 420

Merit: 250

some times the case, but its also harder to read and maintain.

sandos

sr. member

Activity: 440

Merit: 250

#SWGT CERTIK Audited

Well, I thought modern compilers just took that as a hint, and they don't always respect it. I could be wrong though.

Ummon

newbie

Activity: 7

Merit: 0

I just take a look in the bitcoin source code and I find tons of inline functions/methods. Usually, inlining is a very bad idea, it can decrease performance. Inlining should only be made if necessary and should be benchmarked to check if there is some gain.

What do you think?

Topic: Why so many 'inline' ? (Read 1354 times)