Skip to content
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

Enable "alternative module loading" approach for Alpaka modules #40564

Merged
merged 5 commits into from Feb 1, 2023

Conversation

makortel
Copy link
Contributor

PR description:

This PR enables the "alternative module loading" functionality for Alpaka modules (following what I presented in https://indico.cern.ch/event/1208060/#16-portable-configuration-with). In order to use this mechanism, the configuration needs to load HeterogeneousCore.AlpakaCore.ProcessAcceleratorAlpaka_cfi, and define the modules in the configuration with @alpaka postfix in the type name along

# selects at run time whether alpaka_serial_sync::FooProducer or alpaka_cuda_async::FooProducer is used
process.foo = cms.EDProducer("FooProducer@alpaka", ...)

The syntax works for EDProducers, EDAnalyzers, EDFilters, and ESProducers.

The backend can also be set explicitly via

process.foo = cms.EDProducer("FooProducer@alpaka",
    ...,
    alpaka = cms.untracked.PSet(
        backend = cms.untracked.string("serial_sync") # or cuda_async
    )
)

The validity of the explicitly chosen backend is checked at the time the configuration is processed at the worker node, and value that is incompatible with the node hardware (or process.options.accelerators) leads to an exception being thrown. It follows that this approach of defining Alpaka modules with explicitly selected backend does not really work with SwitchProducer (where all modules need to be constructed in the C++ side).

An alternative design that was considered was to encode the backend selection information in the C++ type field (e.g. after @alpaka). Expressing it in the configuration parameters instead allows the backend selection to be easily customized after the module definition (e.g. with a Modifier), and allows the selection logic to be extended with little technical constraints in the future (e.g. selected modules could use TBB when running on CPU).

The benefits of this model over SwitchProducer include

  • works also with SCRAM_ARCHs that don't support all accelerator backends (or anything beyond CPU)
  • works also for EDAnalyzer, EDFilter, and ESProducer in addition of EDProducer
  • reduces the duplication of module parameters (at least in simple cases)
  • allows all module member functions (including constructors) to use backend device specific functionality without any explicit checks about "if the backend is enabled"
Potential discussion points
  • The nomenclature for declaring "Alpaka modules" with @alpaka suffix
  • The nomenclature for setting the module's backend explicitly
  • Whether the backend selection PSet should be visible in the generated cfi file (and thus be visible for ConfDB parsing)
  • For what exactly the cfi files should be generated?
    • This PR takes a perhaps too big step of generating cfi file only for FooProducer@alpaka. An alternative could be to generate cfi files also for serial_sync::FooProducer and cuda_async::FooProducer for some amount of time.
  • When to add the loading of HeterogeneousCore.AlpakaCore.ProcessAcceleratorAlpaka_cfi to Configuration.StandardSequences.Accelerators_cff

PR validation:

Unit tests run.

@cmsbuild
Copy link
Contributor

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40564/33797

Code check has found code style and quality issues which could be resolved by applying following patch(s)

Instead of generating a cfi file for each Alpaka backend for each module
@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40564/33798

  • This PR adds an extra 28KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @makortel (Matti Kortelainen) for master.

It involves the following packages:

  • FWCore/ParameterSet (core)
  • HeterogeneousCore/AlpakaCore (heterogeneous)
  • HeterogeneousCore/AlpakaTest (heterogeneous)

@cmsbuild, @smuzaffar, @Dr15Jones, @makortel, @fwyzard can you please review it and eventually sign? Thanks.
@missirol, @wddgit, @rovere this is something you requested to watch as well.
@perrotta, @dpiparo, @rappoccio you are the release manager for this.

cms-bot commands are listed here

@makortel
Copy link
Contributor Author

enable gpu

@makortel
Copy link
Contributor Author

@cmsbuild, please test

@fwyzard
Copy link
Contributor

fwyzard commented Jan 19, 2023

Personally I'd like something like

process.foo = cms.PortableEDProducer("FooProducer", ...

over

process.foo = cms.EDProducer("FooProducer@alpaka", ...

but it's just a matter of taste - I have not thought about any possible implications.

@fwyzard
Copy link
Contributor

fwyzard commented Jan 19, 2023

An alternative design that was considered was to encode the backend selection information in the C++ type field (e.g. after @alpaka).

Do you mean something like

process.foo = cms.EDProducer("FooProducer@alpaka@serial_sync", ...

?

But then isn't it simpler to just use the explicit module name,

process.foo = cms.EDProducer("alpaka_serial_sync::TestAlpakaProducer", ...

?

@makortel
Copy link
Contributor Author

Following the discussion in the HLT GPU developments meeting on Monday I updated the PR to add back the the cfi generation of the Alpaka modules with the explicit per-backend namespaces

This change has one consequence that is worth of noting: users calling ConfigurationDescriptions::add() in the fillDescriptions() must explicitly disambiguate the module labels for different backends.

@fwyzard
Copy link
Contributor

fwyzard commented Jan 31, 2023

+heterogeneous

@makortel
Copy link
Contributor Author

+core

@cmsbuild
Copy link
Contributor

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. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2)

@makortel
Copy link
Contributor Author

@cmsbuild, please test

Probably better to refresh tests...

@cmsbuild
Copy link
Contributor

cmsbuild commented Feb 1, 2023

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-708a0f/30301/summary.html
COMMIT: f93cd75
CMSSW: CMSSW_13_0_X_2023-01-31-1100/el8_amd64_gcc11
Additional Tests: GPU
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/40564/30301/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • You potentially added 39 lines to the logs
  • Reco comparison results: 10 differences found in the comparisons
  • DQMHistoTests: Total files compared: 49
  • DQMHistoTests: Total histograms compared: 3555495
  • DQMHistoTests: Total failures: 9
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3555464
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 48 files compared)
  • Checked 211 log files, 162 edm output root files, 49 DQM output files
  • TriggerResults: no differences found

GPU Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 9 differences found in the comparisons
  • DQMHistoTests: Total files compared: 4
  • DQMHistoTests: Total histograms compared: 19862
  • DQMHistoTests: Total failures: 287
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 19575
  • DQMHistoTests: Total skipped: 0
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 3 files compared)
  • Checked 12 log files, 9 edm output root files, 4 DQM output files
  • TriggerResults: found differences in 2 / 3 workflows

@rappoccio
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants