[poly_collection] Two remarks
Just as Pete Bartlett mentioned, I'm also a fan of Joaquín's Multi-Index, which I'm used in production for many years as well. My only complaint about his proposed Poly-Collection is the fact I can't leverage and thus benefit from the performance of it, in a multi-index scenario, but as Joaquín already answered a few months ago, that's off-topic and by design, I know :) Many of my BMIs have a by-type index, and the type-partitioned storage of those in contiguous memory for by-type scans would be (greatly?) beneficial. I'd be willing to give up some iterator guarantees BMI provides, as a node-based container, for intelligent contiguous storage of elements, without myself having to maintain by-value homogeneous containers with a manually maintained BMI of polymorphic pointers to those containers' elements. My second remark is about parallelism. I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage. And perhaps even on the write side, rather than having to make the whole container thread-safe, but external mutexing for example, provide ways for a more granular thread-safety by type or segment perhaps. Again, probably off topic, but hardly something you can "add from the outside" I think, and why I mention it here and now. As merely a user of Boost, I don't feel qualified as a reviewer, beyond the two above remarks. Thanks, --DD
Thanks Dominique, We'll take your comments to the review summary as improvement notes. best, Ion
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga via Boost Sent: 09 May 2017 14:24 To: boost@lists.boost.org Cc: Ion Gaztañaga Subject: Re: [boost] [poly_collection] Two remarks
Thanks Dominique,
We'll take your comments to the review summary as improvement notes.
IMO Dominique and Pete Bartlett's comments/notes are both well-informed and should count as reviews with a clear 'yes'. The review form specifically asks "How much do you know about the subject?" to provide guidance to the review manager on how much weight to attach to the review. The review managers decision should not be a simple vote, counting 'Yes' and 'No' to get a result, but a nuanced assessment of the various comments taking account of the expertise of the reviewer. So everyone should make a review, however slightly informed they are. Even a totally uninformed "I didn't understand what this library is supposed to do, or how I should use it" review is useful because it suggests that the documentation is poor. It's also useful to know that people are using the library, even if they don't have a clue how it works. So I'd encourage everyone not to be shy and to answer *all* the review questions, especially the 'how much do you know' and most important including the final 'yes/no' question. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 5/10/17 1:36 AM, Paul A. Bristow via Boost wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga via Boost Sent: 09 May 2017 14:24 To: boost@lists.boost.org Cc: Ion Gaztañaga Subject: Re: [boost] [poly_collection] Two remarks
Thanks Dominique,
We'll take your comments to the review summary as improvement notes.
IMO Dominique and Pete Bartlett's comments/notes are both well-informed and should count as reviews with a clear 'yes'.
The review form specifically asks "How much do you know about the subject?" to provide guidance to the review manager on how much weight to attach to the review.
The review managers decision should not be a simple vote, counting 'Yes' and 'No' to get a result, but a nuanced assessment of the various comments taking account of the expertise of the reviewer.
So everyone should make a review, however slightly informed they are. Even a totally uninformed "I didn't understand what this library is supposed to do, or how I should use it" review is useful because it suggests that the documentation is poor.
It's also useful to know that people are using the library, even if they don't have a clue how it works.
So I'd encourage everyone not to be shy and to answer *all* the review questions, especially the 'how much do you know' and most important including the final 'yes/no' question.
+1 Robert Ramey
El 09/05/2017 a las 14:27, Dominique Devienne via Boost escribió:
Just as Pete Bartlett mentioned, I'm also a fan of Joaquín's Multi-Index, which I'm used in production for many years as well.
My only complaint about his proposed Poly-Collection is the fact I can't leverage and thus benefit from the performance of it, in a multi-index scenario, but as Joaquín already answered a few months ago, that's off-topic and by design, I know :)
I can't add much more to our previous conversation on this subject. Those interested can recover that thread from https://lists.boost.org/Archives/boost/2016/11/231455.php
[...]
My second remark is about parallelism. I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage. And perhaps even on the write side, rather than having to make the whole container thread-safe, but external mutexing for example, provide ways for a more granular thread-safety by type or segment perhaps. Again, probably off topic, but hardly something you can "add from the outside" I think, and why I mention it here and now.
This is an interesting topic. It should be relatively easy to write a
parallel for_each that
spawns a parallel task for each segment, each of which can in its turn
parallelize work
on its data. I can try to play with this idea to see how it fares
performancewise.
As for thread safety, polymorphic containers do already have the nice
property that
concurrent writes to different (preexisting) segments can be done safely:
boost::base_collection<sprite> c;
c.register_types
participants (5)
-
Dominique Devienne -
Ion Gaztañaga -
Joaquin M López Muñoz -
Paul A. Bristow -
Robert Ramey