Bitcoin Forum
August 20, 2017, 02:42:18 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why so many 'inline' ?  (Read 1175 times)
Ummon
Newbie
*
Offline Offline

Activity: 7


View Profile WWW
May 17, 2011, 11:26:08 AM
 #1

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?
1503196938
Hero Member
*
Offline Offline

Posts: 1503196938

View Profile Personal Message (Offline)

Ignore
1503196938
Reply with quote  #2

1503196938
Report to moderator
1503196938
Hero Member
*
Offline Offline

Posts: 1503196938

View Profile Personal Message (Offline)

Ignore
1503196938
Reply with quote  #2

1503196938
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
sandos
Member
**
Offline Offline

Activity: 106


View Profile
May 17, 2011, 01:11:30 PM
 #2

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

Activity: 420



View Profile
May 17, 2011, 01:27:51 PM
 #3

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

ZOMG Moo!
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
May 17, 2011, 05:09:35 PM
 #4

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

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 17, 2011, 09:36:56 PM
 #5

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.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 17, 2011, 10:12:07 PM
 #6

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

    goatpig
    Legendary
    *
    Online Online

    Activity: 1582

    Armory Developer


    View Profile
    May 17, 2011, 11:11:10 PM
     #7

    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.

    Gavin Andresen
    Legendary
    *
    qt
    Offline Offline

    Activity: 1652


    Chief Scientist


    View Profile WWW
    May 18, 2011, 01:21:43 AM
     #8

    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.

    How often do you get the chance to work on a potentially world-changing project?
    Jim Hyslop
    Member
    **
    Offline Offline

    Activity: 98


    View Profile
    May 18, 2011, 03:12:10 AM
     #9

    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

    Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
    wumpus
    Hero Member
    *****
    qt
    Offline Offline

    Activity: 798

    No Maps for These Territories


    View Profile
    May 18, 2011, 04:34:07 PM
     #10

      • 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
      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
      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]

      Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
      Pages: [1]
        Print  
       
      Jump to:  

      Sponsored by , a Bitcoin-accepting VPN.
      Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!