Hi Willem, Milosz pasted a file inline. Facebook's upstream repo is https://github.com/facebook/folly (Mr. Google), but what I was agreeing is, for the present, if we can't realize boost small_vector, we might adapt just that type from Folly for the short term (that was Milosz meaning, in this thread). (So don't panic ;) Matt ----- Original Message ----- > From: "Willem Jan Withagen" <wjw@xxxxxxxxxxx> > To: "Matt Benjamin" <mbenjamin@xxxxxxxxxx>, "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx> > Cc: "Casey Bodley" <cbodley@xxxxxxxxxx>, "Sage Weil" <sweil@xxxxxxxxxx>, ceph-devel@xxxxxxxxxxxxxxx > Sent: Thursday, February 4, 2016 7:06:14 AM > Subject: Re: inline vector container > > On 3-2-2016 23:10, Matt Benjamin wrote: > > I'll prioritize this. Using more of folly may be a worthy project as well, > > but that can wait for later... :) > > Hi Matt, > > Can you give me a URL for the folly stuff. > Since I cannot find any reference to it in the FreeBSD ports. > > I think I'd otherwise prefer Boost, since the ports already contains a > fair amount of Boost stuff. > > Currently I have installed: > boost-all-1.55.0 The "meta-port" for boost libraries > boost-docs-1.55.0 Documentation for libraries from boost.org > boost-jam-1.55.0 Build tool from the boost.org > boost-libs-1.55.0_9 Free portable C++ libraries (without Boost.Python) > > But I see that the new ports have migrated to: > /usr/ports/devel/boost_build/Makefile:PORTVERSION= 2.0.m12 > > So that would move it beyond 1.6, I presume. > > --WjW > > > > 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). > >> > > > > -- > 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 > -- -- 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
