[RFC] Add tests and rudimentary protections for default-constructed PortableCollections #44844
Conversation
…eCollections Also add tests for zero-sized PortableCollections
|
cms-bot internal usage |
| View& view() { | ||
| assert(isValid()); | ||
| return view_; | ||
| } |
There was a problem hiding this comment.
Alternatively the View accessors could be left unchecked, and require the users to explicitly check isValid() or/and the column/scalar accessors of the View to be non-nullptr when it is not clearly guaranteed that the PortableCollection is non-default constructed.
(we could also throw an exception instead of assert(), but maybe the use of default-constructed PortableCollection could be more of a logic error rather than something that would depend e.g. on the data?)
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-44844/40093
|
|
A new Pull Request was created by @makortel for master. It involves the following packages:
@fwyzard, @cmsbuild, @makortel can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
| //REQUIRE(coll->num() == 42); | ||
|
|
||
| // CopyToDevice<PortableHostCollection<T>> is not defined | ||
| #ifndef ALPAKA_ACC_CPU_B_SEQ_T_SEQ_ENABLED |
There was a problem hiding this comment.
These #ifdefs could be removed with #43969
|
enable gpu |
|
@cmsbuild, please test |
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ef15bb/39082/summary.html Comparison SummaryThere are some workflows for which there are errors in the baseline: Summary:
GPU Comparison SummarySummary:
|
|
Are there any use case for a default-constructed PortableCollection, other than the ROOT dictionary ? If that is the only use case, could we make the default constructor private, and somehow declare the ROOT dictionary stuff as a friend ? |
I think that a 0-size PortableCollection should be a well-defined object, with a device and a 0-size buffer associated to it. The reason that in general we cannot do this for a default constructed PortableCollection is that we don't know what device to use. |
It's a good question, and I'd be tempted to answer "no". On the other hand, this issue came up with code along // in class definition
device::EDPutToken<PortableCollection<...>> putToken_;
...
// in produce() function
if (inputVector.empty()) {
iEvent.emplace(putToken_); // leads to default-constructed PortableCollection
}. It's not necessarily a good use case, but it is easy to do.
I don't know how easy it would be to figure out the components in ROOT that need the default constructor (some of them might even be in anonymous namespaces). In addition, there are some code paths where With @Dr15Jones we were not able to come up with hacks that would allow hiding the default constructor from user code (or even reporting with static analyzer) would not explode to our face in some way. (in the long term it would be great to be able to move |
|
I see. Can we prevent at least default-constructed |
I agree 0-size PortableCollection should be defined at least to the extent of having a device, and the recommended way of asking the size returns 0. What would be the meaning of the 0-size buffer? Whatever happens to be returned by the underlying allocator of the backend? E.g. for Does Alpaka itself make any assumptions on whether the underlying allocator returns a Would we want a buffer object, but containing a
Right, I thought the host case too. Device itself is known, but the we would not be able to make the "queue association" (i.e. cached allocation). I'm not sure if that would really matter though for this corner case. |
The additional indirection (or wrapping) via |
cmsbuild
added
reconstruction-pending
core-pending
tests-pending
code-checks-pending
trk
and removed
tests-approved
code-checks-approved
labels
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-44844/40142
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
Allowing That made me wonder what to do with the moved-from state of PortableCollection (especially in conjunction with In e4d2b53 I explored what it would entail to make On one hand, the present moved-from state fulfills the standard's requirement of the object being destructible, and "minimal recommendation of the core guidelines" of the object being assignable. I.e. when used properly, things work. On the other hand, e.g. |
PR description:
The HCAL CUDA->Alpaka porting work by @kakwok demonstrated bad behavior with default-constructed PortableCollection, so I added some tests to demonstrate those (at one point the HCAL work seemed to point to some strange behavior also for zero-sized PortableCollection, but I was not able to replicate that, and the strange behavior also didn't repeat later with the HCAL Alpaka code).
A default-constructed PortableCollection is in a state where it has no buffer. The PortableCollection interface does not provide a way to check the state, and therefore a caller has no way to know if
PortableCollection::buffer()leads to defined or undefined behavior (becausestd::optional<T>::operator*()leads to undefined behavior if theoptionaldoes not contain value). This PR takes one attempt to add a functionPortableCollection::isValid()that allows checking the validity, and addsassert()s to all accessors (plussize()to be able to access the SoA size without theassert(). I'm not sure if this the behavior we really want, but at least it is a starting point for a discussion.The tests for 0-size SoA Layout and PortableCollection are for ensuring valid behavior when the SoA has also scalars in addition to columns. (and now I'm wondering what should be the behavior of a 0-size PortableCollection for a SoA that has only columns?)
The PortableObject and PortableMultiCollection should also be treated consistently, but I wanted to get feedback first on the direction we want to go first.
PR validation:
Unit tests pass
If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
Possibly to be backported to 14_0_X