Subject: Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2017-05-08 13:48:58
Ion GaztaÃ±aga Via Boost wrote:
> The formal review of JoaquÃn M. LÃ³pez MuÃ±oz's PolyCollection library
> starts today.
> I'd like to encourage your participation as the proposed library is
> small and focused, and reviewers don't need to be domain experts to
> appreciate the potential usefulness of the library and propose
> PolyCollection implements fast containers of polymorphic objects.
> Typically, polymorphic objects cannot be stored directly in regular
> containers and need be accessed through an indirection pointer, which
> introduces performance problems related to CPU caching and branch
> prediction. Boost.PolyCollection implements a novel data structure
> that is able to contiguously store polymorphic objects without such
> indirection, thus providing a value-semantics user interface and
> better performance. Three polymorphic collections are provided:
The library looks very well and I think it'd be a valuable contribution
But I'm wondering, would it make sense to expand the scope of the
library? Besides storing polymorphic data of the same type based on
run-time info to improve caching there are situations when data might be
divided into hot and cold data based on compile-time info. E.g. a
"vector" of tuples could internally store tuple of vectors and provide
interface allowing to access tuples more or less transparently. Storing
hot and cold data in different but contigeous parts of memory would also
improve caching. Since the principle is similar, would it have sense to
have both types of collections in one library? Not necessarily now, but
if this was a good idea then the name of the library would have to be
changed into something more general.
I noticed that in the documentation a word "container" is used WRT poly
collections. AFAIU this is not correct because poly_collection doesn't
meet the requirements of C++ container as defined in the standard, i.e.
allocator_traits<allocator_type>::construct should be called only for
the element type (220.127.116.11) but poly_collection contains
std::unordered_map and packed_segment contains std::vector which
constructs objects of their own value types. Also Models call operator
new in make function. If that's correct and I'm not missing anything
then I suggest using the word "collection" consistently in the docs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk