[boost] Re: Re: Formal Review: Assignment Library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-09 02:00:19

Hi Thorsten,

>> The point is: making the function 'inline', either with explicit keyword
> or
>> by placing it in the class body *increases* the chances that it will be
>> inlined. And since inlining here can cause code bloat, it's better not to
>> increase those chances.
> 
> I agree I should investigate how my lib perform in this regard. I do think
> that we wan't
> all the inlining that we can get. For example,
> 
> vector<int> v;
> v += 1,2;
> 
> should preferably be expanded to
> 
> vector<int> v;
> v.push_back( 1 ); v.push_back( 2 );
> 
> I don't see any benefit of another layer of function-calls (except larger
> code size:-)).

Right, in this case inline expansion is ok. Though even if there's another
layer of function call the only drawback would be a single instantination
of that other function, plus extra time for argument passing.

>> I've just sketched an example which can be found at
>>
>>    http://zigzag.cs.msu.su:7813/inline
>>
>> There are two files -- one with in-class definition and one with
>> out-of-class definition. Both are compiled with -O3 but the function is
>> inlined only in the first example and the number of instructions needed
>> to each call grows from 4 to 13. In a real example the difference might
>> be smaller, but it also might be larger :-(
> 
> with vc7.1 and como4.3 the results are:
> 
> -rwxrwxrwx    1 nesotto  None       135168 Apr  9 00:12 cl_inline.exe
> -rwxrwxrwx    1 nesotto  None       135168 Apr  9 00:08 cl_inline2.exe
> -rwxrwxrwx    1 nesotto  None       950272 Apr  9 00:07 como_inline.exe
> -rwxrwxrwx    1 nesotto  None       950272 Apr  9 00:08 como_inline2.exe

950K for a tiny program? Oh, anyway, I think this can have two explanations
1. Those compilers have different opinions about inlining (which does not
disprove the statement that 'inline' increases chances for inlining).
2. The binary size is rounded to some 'page' boundary

> 
>> It was some time ago, so situation might have improved in gcc or in
>> libstdc++, but generally, unnecessary inlining will still increase the
> code
>> size.
> 
> perhaps; except when it decreases code size. :-) Arguable it would be good
> to see more what
> other compilers do; and I would like to see your code optimized for size
> (-O3 is for speed, right).

It would be also good to have tests with 1 call, 10 calls, 20 calls and so
on, so that we can draw nice plot, instead of computing the number of
assembly instructions ;-) Ok, I've wrote a script to measure that, please
see the results in 

   http://zigzag.cs.msu.su:7813/inline/data.pdf

and data for optimization for space (-Os) in in

   http://zigzag.cs.msu.su:7813/inline/data_space_optimization.cvs

(and is not much different from -03)

- Volodya