-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SwitchProducer mechanism to allow runtime decision which algorithm implementation to run #25439
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25439/7508 |
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: DataFormats/Common @cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Doesn't this go in the opposite direction of what we discussed earlier, with the possibility of having different "chain" of modules used for e.g. the CPU vs GPU reconstruction ? Or do you expect the switch to be used only for the last module in the chain, and relay on the dependencies to trigger different chains ? But, wouldn't that lead to different provenances ? |
@cmsbuild, please test |
The tests are being triggered in jenkins. |
No, enabling that has been the plan all along.
Exactly, the switch is used only for the last module in the chain, and the prefetching (along data dependencies) takes care of the rest. Or to be more precise, the switch should be used for each step of the chain for which a product is (possibly) needed in the CPU (such that a CPU version of the algorithm exists as well). E.g. for the current state of patatrack (#25353) there would be switches for
Here all
At the event level provenance ( |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
The code-checks are being triggered in jenkins. |
Tidied up the history. Apparently nowadays GitHub provides a nice link to show the diff of a force-push. That provides a way to see a diff of an update even if some earlier commits got updated (as long as the base commit stays the same). |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25439/7862
|
Pull request #25439 was updated. @cmsbuild, @smuzaffar, @Dr15Jones can you please check and sign again. |
@cmsbuild, please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
This PR provides an implementation for a
SwitchProducer
to allow a runtime decision on which EDProducer from a given set to run for a given module label. The main use case in mind are heterogeneous/offloaded/accelerated algorithms, where we would run the accelerated EDProducer if the accelerator device is available in the system, and run the "legacy" CPU EDProducer otherwise.For a given accelerator type, the generic
SwitchProducer
is supposed to be inherited alongHere the deriving class provides a dictionary of possible cases along with functions that return a
(bool, int)
tuple. Thebool
tells whether that device type is enabled on the machine, and theint
gives a priority of that device wrt. other devices.SwitchProducer.getCpu()
returns a function for the CPU (always enabled, priority1
). Note that in order to be able to pickle the configuration, these functions have to be at (python) module level (i.e. e.g. lambdas or static methods are not sufficient).The decision logic chooses the case that has the largest priority among those that are enabled. The decision is made at the point where the python configuration is transformed for C++, i.e. in case of production at the worker node.
The switch decision does not affect the configuration hash, meaning that the framework will consider a run/lumi/event produced with
isFooDeviceEnabled() == False
the same as withTrue
.The concrete
SwitchProducerFoo
would then be used along (e.g. in acfi
file)In this example, if
isFooDeviceEnabled()
returnsTrue
=>BarOnFooDevice
EDProducer is runFalse
=>Bar
EDProducer is runThe switched EDProducers are required to declare exactly the same products with the
produces()
call.When a client asks for a products if
bar
, it will get pointed to the exactly the sameedm::Wrapper
that contains the product by the chosen EDProducer. The additional "layer' is, however, tracked in provenance, such that the parent of a productbar
isbar@cpu
orbar@foo
, depending which one of the EDProducers was run.The python interface is likely to evolve with more experience with it, with accelerated EDProducers, and with devices beyond CUDA. Note that this PR adds only the generic infrastructure, a CUDA-specific implementation will follow in a separate PR (or e.g. as part of the effort of #25353).
Tested in 10_4_0_pre3, no changes expected.