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
