boost.foreach overhead
On 10/9/2010 John Carmack of id Software wrote on his Twitter account: “@ID_AA_Carmack: It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.” This made me think again about the overhead introduced with boost foreach. Is the overhead really this large as he makes it sound? Are there heuristics to when to use foreach according to the expected iteration counts? Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | Faculty of Media - Virtual Reality Systems Group | Tel. +49 (0) 3643 - 58 3734
On 17/10/10 18:12, Christopher Lux wrote:
On 10/9/2010 John Carmack of id Software wrote on his Twitter account: “@ID_AA_Carmack: It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.”
This made me think again about the overhead introduced with boost foreach. Is the overhead really this large as he makes it sound? Are there heuristics to when to use foreach according to the expected iteration counts?
I haven't counted exact number of steps, though it's unclear to me what John means exactly. Remembering some benchmarks on the list and assuming nothing has changed in the macro that could decrease its performance, I'd not be worried: http://boost.2283326.n4.nabble.com/BOOST-FOREACH-slow-tp2652445p2652464.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Sun, Oct 17, 2010 at 10:12, Christopher Lux <christopherlux@gmail.com> wrote:
On 10/9/2010 John Carmack of id Software wrote on his Twitter account: “@ID_AA_Carmack: It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.”
This made me think again about the overhead introduced with boost foreach. Is the overhead really this large as he makes it sound? Are there heuristics to when to use foreach according to the expected iteration counts?
If he says "steps", I figure he must mean in a debugger. Since performance in generic C++ code relies heavily on inlining, I'm not surprised it's high as the number is mostly meaningless.
On Sun, Oct 17, 2010 at 5:01 PM, Scott McMurray <me22.ca+boost@gmail.com>wrote:
If he says "steps", I figure he must mean in a debugger. Since performance in generic C++ code relies heavily on inlining, I'm not surprised it's high as the number is mostly meaningless.
Exactly. I wouldn't worry about how long it takes to step through in a debugger unless that's something that is severely impacting your development. He did say one thing that hurts though: "We do not use boost on internal projects. The experience with external projects using it has not been positive". I'd like to here more about this since it seems that many video game studios, not just id, are like this. Though, to be hones, I'm surprised John Carmack even uses boost at all. I always heard he was more like Linus... -- -Matt Calabrese
On Sun, Oct 17, 2010 at 4:23 PM, Matt Calabrese <rivorus@gmail.com> wrote:
I'd like to here more about this since it seems that many video game studios, not just id, are like this. Though, to be hones, I'm surprised John Carmack even uses boost at all. I always heard he was more like Linus...
As a friend at Epic once told me: 1) Fear of perf hits in stdlib abstractions, exceptions, and operators not always directly mapping to single obvious instructions. 2) Multiple template instantiations for one algorithm are perceived as bloat. 3) Memory usage of stdlib collections doesn't fit their requirements. 4) Not all C++ devs are competent with the more advanced features, and are restricted to the simpler ones so that everyone can maintain everything. It seems like, for the most part, (1) and (2) aren't issues anymore. (3) is handled pretty well by Intrusive. (4) is the only big concern left, and I don't know how that could be solved. -- Cory Nelson http://int64.org
On 17 Oct 2010, at 22:01, Scott McMurray wrote:
On Sun, Oct 17, 2010 at 10:12, Christopher Lux <christopherlux@gmail.com> wrote:
On 10/9/2010 John Carmack of id Software wrote on his Twitter account: “@ID_AA_Carmack: It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.”
This made me think again about the overhead introduced with boost foreach. Is the overhead really this large as he makes it sound? Are there heuristics to when to use foreach according to the expected iteration counts?
If he says "steps", I figure he must mean in a debugger. Since performance in generic C++ code relies heavily on inlining, I'm not surprised it's high as the number is mostly meaningless.
Mostly meaningless? Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible. It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard. Chris
On 10/17/2010 2:39 PM, Christopher Jefferson wrote:
Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible.
It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard.
What debugger do you use? Visual Studio doesn't give me this grief. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sun, Oct 17, 2010 at 3:47 PM, Eric Niebler <eric@boostpro.com> wrote:
On 10/17/2010 2:39 PM, Christopher Jefferson wrote:
Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible.
It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard.
What debugger do you use? Visual Studio doesn't give me this grief.
Ditto, but even if it did I could setup a debugging filter in it to ignore the extra steps in the VS debugger, can you not do that in GDB?
OvermindDL1 wrote:
On Sun, Oct 17, 2010 at 3:47 PM, Eric Niebler <eric@boostpro.com> wrote:
On 10/17/2010 2:39 PM, Christopher Jefferson wrote:
Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible.
It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard.
What debugger do you use? Visual Studio doesn't give me this grief.
Ditto, but even if it did I could setup a debugging filter in it to ignore the extra steps in the VS debugger, can you not do that in GDB?
Suprise -- no, you cannot. - Volodya
On Mon, Oct 18, 2010 at 5:03 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
OvermindDL1 wrote:
On Sun, Oct 17, 2010 at 3:47 PM, Eric Niebler <eric@boostpro.com> wrote:
On 10/17/2010 2:39 PM, Christopher Jefferson wrote:
Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible.
It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard.
What debugger do you use? Visual Studio doesn't give me this grief.
Ditto, but even if it did I could setup a debugging filter in it to ignore the extra steps in the VS debugger, can you not do that in GDB?
Suprise -- no, you cannot.
As GDB is completely scriptable you can of course do that http://tromey.com/blog/?p=522 Regards, Kai
Kai Schroeder wrote:
On Mon, Oct 18, 2010 at 5:03 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
OvermindDL1 wrote:
On Sun, Oct 17, 2010 at 3:47 PM, Eric Niebler <eric@boostpro.com> wrote:
On 10/17/2010 2:39 PM, Christopher Jefferson wrote:
Having to step through 69 steps to go through each stage of a for loop makes debugging almost impossible.
It is for precisely this reason that most projects I work on forbid BOOST_FOREACH, and a similar preprocessing madness. They just make debugging, and tracking down compile-time errors, too hard.
What debugger do you use? Visual Studio doesn't give me this grief.
Ditto, but even if it did I could setup a debugging filter in it to ignore the extra steps in the VS debugger, can you not do that in GDB?
Suprise -- no, you cannot.
As GDB is completely scriptable you can of course do that http://tromey.com/blog/?p=522
That blog post is not actually implementing step filters, for all I can tell. Of course, given that GDB is (i) computer program and (ii) open-source, you can do pretty much anything, even without Python scripting, however just because it's theoretically possible, this is not something that average GDB user would even try. - Volodya
At Sun, 17 Oct 2010 19:12:01 +0200, Christopher Lux wrote:
On 10/9/2010 John Carmack of id Software wrote on his Twitter account: “@ID_AA_Carmack: It took 69 single steps to get past a BOOST_FOREACH() statement. Madness.”
This made me think again about the overhead introduced with boost foreach. Is the overhead really this large as he makes it sound? Are there heuristics to when to use foreach according to the expected iteration counts?
Without more information about what he was actually doing, it's hard to say whether his expectations are totally unrealistic or not. You can do a BOOST_FOREACH over a container rvalue; who knows if he was actually seeing the construction steps for the container or not? Who knows if he was stepping by ASM instruction? I'd say that tweet is totally inconclusive and unhelpful. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (11)
-
Christopher Jefferson -
Christopher Lux -
Cory Nelson -
David Abrahams -
Eric Niebler -
Kai Schroeder -
Mateusz Loskot -
Matt Calabrese -
OvermindDL1 -
Scott McMurray -
Vladimir Prus