[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-users
Subject:    Re: [Boost-users] Container iteration macro that is equivalent to
From:       Erik <sigra () home ! se>
Date:       2007-10-11 23:10:07
Message-ID: 470EAD4F.4050202 () home ! se
[Download RAW message or body]

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.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users


[prev in list] [next in list] [prev in thread] [next in thread]