Re: [Boost-users] Container iteration macro that is equivalent to handcoded iteration?

From: Erik (sigra_at_[hidden])
Date: 2007-10-11 19:10:07

Andrew Holden skrev:
> Erik wrote:
>   
>> Andrew Holden skrev:
>>     
>>> Erik wrote:
>>>
>>>       
>>>> Unfortunately it does not look so good for BOOST_FOREACH after this
>>>> modification. It will increase to 24 instructions, while the
>>>> handcoded is still only 21. I created a script
>>>> (attached) to test the examples systematically with different
>>>> compiler versions and optimization levels.
>>> Forgive me if this was answered in an earlier post,
>>>       
>> The answer is available by executing the test script in my
>> previous post and then running the diff command that I showed in that
>> post: diff -dU2 iterate_vector-member-g++-4.2.0-O3.s
>> BOOST_FOREACH-member-g++-4.2.0-O3.s|kompare -
>>
>>     
>>> but how complex is the loop body, including the complexity of any functions it calls?
>>>       
>> The size of the loop body increases from 6 to 7 instructions
>> and the code before the loop increases with 2 instructions.
>>     
>
> Okay.  I see that the loop body contains a call to a function "f", which
> is not defined.  Here is the code from one of the tests:
>
> //Begin BOOST_FOREACH-parameter.cc
> void f(float);
> #include <boost/foreach.hpp>
> #include <vector>
>
> void g(const std::vector<float> & v) {
>
>    BOOST_FOREACH(float i, v)
>       f(i);
> }
> //End BOOST_FOREACH-parameter.cc
>   
This is the test case where BOOST_FOREACH actually has no overhead with
the right compiler version and optimization level. To study the problem,
look at BOOST_FOREACH-member instead.

> We would need to know the contents of f before we can really discuss the consequences of the extra instructions in BOOST_FOREACH.
No we do not. The compiler does not need to know the contents of f to
generate that code. Neither do we need to know the contents of f to
discuss the code that the compiler generates in this case. I
deliberately left f undefined so that loop efficiency can be studied in
isolation.

The advantage of BOOST_FOREACH is isolated to the loops, so to weight
the advantages against the disadvantages, we must study the
disadvantages in isolation as well. Sure, any relatively small
disadvantage in a program construct can be hidden by adding everything
else that the program needs to do to the comparison.

Suppose that 2 out of 3 loops become 12 byte longer with BOOST_FOREACH
and that there are 2 000 loops in a program. That means 16kB. Add to
that somewhat slower execution. Not a huge disadvantage assuming that
the whole program is several MB, but then BOOST_FOREACH is just a small
building block among others.

But I still hope that this can be fixed by improving g++ (or possible
BOOST_FOREACH), so that using BOOST_FOREACH will be strictly better and
not a tradeoff.