I'll prioritize this. Using more of folly may be a worthy project as well, but that can wait for later... :) tx! Matt ----- Original Message ----- > From: "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx> > To: "Casey Bodley" <cbodley@xxxxxxxxxx>, "Matt Benjamin" <mbenjamin@xxxxxxxxxx> > Cc: "Sage Weil" <sweil@xxxxxxxxxx>, ceph-devel@xxxxxxxxxxxxxxx > Sent: Wednesday, February 3, 2016 5:06:57 PM > Subject: RE: inline vector container > > I would say that just pulling the latest boost into the tree and using it for > builds is the best path forward. But I'm in no way competent to make that > kind of change in the build system -- especially during the automake cmake > changeover period. > > > Allen Samuels > Software Architect, Fellow, Systems and Software Solutions > > 2880 Junction Avenue, San Jose, CA 95134 > T: +1 408 801 7030| M: +1 408 780 6416 > allen.samuels@xxxxxxxxxxx > > > -----Original Message----- > From: Casey Bodley [mailto:cbodley@xxxxxxxxxx] > Sent: Wednesday, February 03, 2016 1:26 PM > To: Matt Benjamin <mbenjamin@xxxxxxxxxx> > Cc: Sage Weil <sweil@xxxxxxxxxx>; Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; > ceph-devel@xxxxxxxxxxxxxxx > Subject: Re: inline vector container > > Hi Allen, > > I did spend some time a couple months ago experimenting with a custom > allocator with inline storage for standard containers. You can find my > branch on github at > https://github.com/cbodley/ceph/commits/wip-preallocator. > > I was aiming for a general solution that worked with non-contiguous > containers, but couldn't find a good way to handle deallocations. So the > approach was really only a good fit for std::vector. > > I also had trouble getting it to do the right thing with the copy and move > operators. I found that it was trying to use the new allocator to release > memory that came from the old allocator. Presumably there's a way to make > this work using std::allocator_traits; have you had better luck here? I'd > love to see your prototype. > > I tend to agree that we should go with the boost solution if we can. But if > a) we can't use boost::small_vector in the near-term due to versioning, and > b) we can get a custom version tested and working, it might be worth > pursuing. > > Casey > > ----- Original Message ----- > > Hi, > > > > I think we should go with small_vector for this role, yes. I found > > two issues. First, there are critical defects in small_vector prior > > to boost 1.6.0. Second, though it is header-only, the coupling with > > related version-specific boost types (container, allocator, respective > > detail types, and platform-specific selectors...) seems to make > > pulling it in separately pretty unrealistic as an option. I looked at > > the cost of pulling in and selectively compiling (libs) an entire > > boost 1.6, and that went a lot easier (added less than a minute to my build > > time). > > > > Matt > > > > ----- Original Message ----- > > > From: "Sage Weil" <sweil@xxxxxxxxxx> > > > To: "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx> > > > Cc: ceph-devel@xxxxxxxxxxxxxxx, mbenjami@xxxxxxxxxx, > > > cbodley@xxxxxxxxxx > > > Sent: Wednesday, February 3, 2016 3:04:57 PM > > > Subject: Re: inline vector container > > > > > > On Wed, 3 Feb 2016, Allen Samuels wrote: > > > > One thing that the code base needs is a simple vector container > > > > that is optimized for a small number of elements, i.e., for small > > > > element counts we avoid the malloc/free overhead. But fully > > > > supports being resized into larger containers that are unbounded. > > > > Of course it will need to follow all of the proper object > > > > copy/move semantics so that things like unique_ptr, etc work > > > > correctly. > > > > > > > > I heard rumors that there was one available in the boost world, > > > > but I can’t seem to find it. Do you know about one being > > > > available? > > > > > > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_ > > > vector.html > > > > > > > I’ve been prototyping one myself, just to get re-familiar with all > > > > of the > > > > C++11 move sementics, and trivial constructors, etc. > > > > > > > > The code is pretty complete, but the testing gets rather involved. > > > > There’s > > > > no reason to contain this if it’s available elsewhere. But if it > > > > isn’t I plan on continuing this… > > > > > > I think Casey had prototyped something similar using a custom > > > allocator, too, but I didn't actually look at the result. And Matt > > > talked about just pulling the boost one in-tree until we get updated > > > boost in the supported distros, but I forget if he ran into problems > > > there or not... > > > > > > sage > > > > -- > > -- > > Matt Benjamin > > Red Hat, Inc. > > 315 West Huron Street, Suite 140A > > Ann Arbor, Michigan 48103 > > > > http://www.redhat.com/en/technologies/storage > > > > tel. 734-707-0660 > > fax. 734-769-8938 > > cel. 734-216-5309 > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo > > info at http://vger.kernel.org/majordomo-info.html > > > PLEASE NOTE: The information contained in this electronic mail message is > intended only for the use of the designated recipient(s) named above. If the > reader of this message is not the intended recipient, you are hereby > notified that you have received this message in error and that any review, > dissemination, distribution, or copying of this message is strictly > prohibited. If you have received this communication in error, please notify > the sender by telephone or e-mail (as shown above) immediately and destroy > any and all copies of this message in your possession (whether hard copies > or electronically stored copies). > -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
