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