>> There are a couple of options. We could use vector<bool> (we >> have threads on this data structure in our mail archive) which often >> has a bit packed specialization or boost::dynamic_bitset. >> >> In the interim, a vector<bool> sounds like a decent workaround. I'm worried about performance here. I'm not sure how exactly Set is used, but I'm concerned that it might be a performance critical data structure. I'm not sure of the performance of vector<bool> (then again, I'm not sure of the performance of the existing Set). GNU libstdc++ does not specialize vector<bool> when it's one word, so that's not particularly awesome. I'm pretty sure that dynamic_bitset would be much better. Unfortunately none of them uses the popcount or find first set type of instructions.
>> I'm starting to feel like we should reconsider boost. There's >> certainly a lot of crazy stuff in there, but there's also quite a bit >> of useful stuff. We could require explicit agreement on which parts >> of boost to use to avoid the really scary stuff. > > Are there boost licensing issues or are we jut talking about "M5 style" on > how to use the boost code? I'm not too familiar w/all the pros/cons of Boost > but I'd agree that if there is a faster implementation of some of the common > code we have around, then we should definitely take a look. > > A question I would have to look into is how much faster would the dynamic > bitset from Boost be to a self-managed vector<bool>. If it's negligible, we > could avoid any complications of adding Boost. I would ask similar for the > other objects you mentioned. The cons with boost are two-fold. The first (and most important) is that it'd be another dependency. Dependencies suck because they make it harder to get going with gem5. The second is that boost uses lots of c++ wizardry to make things fast. In many cases, it's not a big deal, but in some of the libraries, it leads to compiler errors that can be truly difficult to debug. The pro is that boost has lots of great stuff in it. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
