Bitset uses bits and is specialized if the number of bits < long it just allocates a single long and stores everything in there. vector<bool> is also specialized to use bits include/c++/version/bits/ stl_bvector.h at least in g++ 4.2.3.
Ali On Sep 23, 2008, at 2:16 PM, [EMAIL PROTECTED] wrote: > I generally agree, except that I'd be a bit surprised (but not > shocked) if > vector<bool> was specialized to use bits. I'll check into this more > at some > point but my vote would be to go with bitset since it sounds like > that would > get us where we'd want to be. > > Gabe > > Quoting Steve Reinhardt <[EMAIL PROTECTED]>: > >> 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 >>>> m5-dev@m5sim.org >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>> >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >> > > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
