I thought vector<bool> was supposed to be a space-optimized bit vector.
I think there are two things going on here: 1. It's an STL type, which means that the implementation probably is a nightmare of layered abstractions that in theory the compiler can figure out and flatten to an efficient piece of code in the common case. If you're single-stepping through the debug version, I'm not surprised that it's a mess, but I also would not be surprised if in the opt version it boils down to roughly equivalent to the optimized code you're proposing. 2. We probably should be using std::bitset rather than std::vector<bool> when possible... the former should be faster since it's non-resizable and thus might have less bounds-checking code. I've been trying to use bitset for this type of thing everywhere I can in m5 (packet flags), and it looks like Kevin is using it in a few places in o3 (though he uses vector<bool> also... not sure if that's intentional). Plus even if vector<bool> is no longer space-optimized I'm sure that bitset is. In any case, we definitely don't want to write a one-off piece of code just for trace flags. If someone can absolutely prove that neither vector<bool> nor bitset is adequate when compiled with optimization, we can consider writing a replacement class for all our bit vectors, but I highly doubt that this is the case. Steve On Tue, Sep 23, 2008 at 11:33 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > You're talking about replacing return flags[t]; with a space optimized > bit vector? I imagine it would help performance some if for no other > reason that the trace flags would fit is a single cache block rather > than spanning multiple as they do now. > > Ali > > > On Sep 23, 2008, at 2:42 AM, Gabe Black wrote: > > > I just finished stepping through some code having to do with PCs in > > simple CPU, and I noticed that not printing DPRINTFs is actually a > > fairly involved process, considering that you're not actually doing > > anything. Part of the issue, I think, is that whether or not a > > traceflag > > is on is stored in a vector of Bools. Since the size of the vector > > won't > > change often (ever?) would it make sense to just make it a char [] and > > use something like the following? > > > > flags[t >> 3] & (1 << (t & 3)); > > > > > > I realize when you've got tracing on you're not going for blazing > > speed > > in the first place, but if it's easy to tighten it up a bit that's > > probably a good idea. The other possibility is that it's actually not > > doing a whole lot but calling through a bunch of functions gdb stops > > at > > one at a time. That would look like a lot of work to someone stepping > > through with gdb but could be just as fast. > > > > Gabe > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
