Update Gaudi version from v36r5.002 to v36r6.000
Update Gaudi version in all relevant projects.
Changes (full list, some are not relevant to ATLAS):
- Improve memory footprint of JobOptionsSvc - gaudi/Gaudi!1304 (merged)
- Delete StatusCodeSvc and its interface - gaudi/Gaudi!1310 (merged)
- Provide diagnostic information instead of SEGV when a bound tool is disabled - gaudi/Gaudi!1330 (merged)
- Change AlgResourcePool to obey isReEntrant() - gaudi/Gaudi!1331 (merged)
- Fix invalid SUCCESS in [Ts]DataSvc::retrieveEntry - gaudi/Gaudi!1333 (merged)
- Update version of Black used in pre-commit - gaudi/Gaudi!1334 (merged)
- Use ofstream from std - gaudi/Gaudi!1335 (merged)
- Fix and deprecate histogram filling with
operator+=
- gaudi/Gaudi!1336 (merged) - Cleanup old, unsed and deprecated code in DataHandles - gaudi/Gaudi!1337 (merged)
- feat: add erase method to PluginSvc Registry class - gaudi/Gaudi!1338 (merged)
- AvalancheSchedulerSvc: Print also event number if a stall is detected - gaudi/Gaudi!1339 (merged)
- Fix clang warning. - gaudi/Gaudi!1340 (merged)
- Fix compilation with gcc12. - gaudi/Gaudi!1341 (merged)
- Make Rndm::Numbers methods const - gaudi/Gaudi!1343 (merged)
- Fix a possible uninitialized variable warning - gaudi/Gaudi!1344 (merged)
- Include GaudiException tag() strings in GaudiAlg functional warning/error messages when caught - gaudi/Gaudi!1345 (merged)
- Support writing ROOT files with LZ4 and ZSTD compression - gaudi/Gaudi!1346 (merged)
- EventIDRage c'tor: Don't reset UNDEF values to 0 - gaudi/Gaudi!1347 (merged)
- Accumulators : drop unused boost includes - gaudi/Gaudi!1349 (merged)
- Prevent usage of histograms with wrong number of coordinates - gaudi/Gaudi!1350 (merged)
- Do not use anonymous namespaces in Histograms headers - gaudi/Gaudi!1351 (merged)
- Fix for allowing full customization of Histograms - gaudi/Gaudi!1352 (merged)
- Allow histograms to be saved in custom directories - gaudi/Gaudi!1353 (merged)
- Use pkgconfig to find gperftools - gaudi/Gaudi!1354 (merged)
- Resolve "race conditions in tests" - gaudi/Gaudi!1356 (merged)
- Modify FetchLeavesFromFile to use IDataManagerSvc::traverseSubTree - gaudi/Gaudi!1357 (merged)
- Update change log and version - gaudi/Gaudi!1358 (merged)
Motivated particularly from the Trigger side by gaudi/Gaudi!1304 (merged) and gaudi/Gaudi!1344 (merged)
Merge request reports
Activity
added full-build full-unit-tests labels
assigned to @rbielski
added 22.0 label
I'm waiting to start the CI after !55596 (merged) because the release, and the CI seem to be broken until then.
added Build review-pending-level-1 labels
✅ CI Result SUCCESS (hash 0ba7447e)Athena DetCommon externals ✅ ✅ cmake ✅ ✅ make ✅ ✅ required tests ✅ ✅ optional tests ✅ ✅ Full details available on this CI monitor view. Check the JIRA CI status board for known problems
✅ Athena: number of compilation errors 0, warnings 0
✅ DetCommon: number of compilation errors 0, warnings 0
📝 For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 56910]added review-approved label and removed review-pending-level-1 label
@rbielski how urgent do you need this update of Gaudi ? Usually the production releases should be kept stable in terms of external dependencies, but if there is a strong motivation for the update and there is evidence that the update is safe then let's update. Gaudi v36r6.000 is used since about 2 weeks in the master branch (!55078 (merged))
Not urgent, but I thought it'd be nice to have for Trigger given that:
- changes are fairly uncontroversial
- Gaudi updates generally don't cause major issues and are much less likely to have physics impact than some other externals
- as you said, it's been running in master and no issues were found
- it provides small but noticeable memory saving thanks to the JobOptionsSvc update (somewhat seen in master ART tests) which might be useful for P1
- it fixes an uninitialised variable which could be the reason for valgrind complaints about our framework (but I've not checked that part in master)
To me it was mostly about the memory savings, but if there is a strong preference against updating I guess we could drop this. Alternatively, we could create
v36r5.004
with just gaudi/Gaudi!1304 (merged) and gaudi/Gaudi!1344 (merged) on top ofv36r5.003
and move to that in 22.0.Let's have a comment from @pberta, @jmaurer, @astruebi, @palacino
Not critical, just would be nice to have. I think the saving would be only O(100MB) per HLT node because I believe the part of memory optimised here is shared between forks.
I could run some tests to evaluate the gains more precisely, but I'm too busy with more critical issues for P1 these days. We can put this on hold for now.
Hi @rbielski,
what is the plan with this MR ? @wlampl just told me that there might be another Gaudi update necessary as soon as the following Gaudi MR gaudi/Gaudi!1369 (merged) made it through all the systems.
If all agree this MR here could go ahead as planned soon or we wait until a new Gaudi version with MR gaudi/Gaudi!1369 (merged) will be available and is well tested in the master branch beforehand (this could take a while).
Cheers, Johannes
Current options are the following, ordered by increasing risk:
- Create a patch tag of atlas/Gaudi only adding gaudi/Gaudi!1369 (merged) on top of the current production release.
- Create a patch tag of atlas/Gaudi adding gaudi/Gaudi!1369 (merged), gaudi/Gaudi!1304 (merged) and gaudi/Gaudi!1344 (merged) on top of the current production release.
- Move to a full new Gaudi release compatible with the upstream gaudi/Gaudi tag including all these changes, without any ATLAS-specific patches.
I think my personal preference at this point would be 2. but it's up to PROC, TrigOps and Software Coordinators to decide.
I would vote for 3. While there is a rather long list of MRs that went into these new Gaudi releases, they are either irrelevant for ATLAS or code quality improvements. All of this has been used in master since quite some time and no problems were reported in ART. Considering the huge amount of changes that go into our production branch in general, these changes in Gaudi are really minor in comparison.
While we're on the topic, let me also mention there is a small yet annoying bug in the scheduler that we'd like to have fixed for HLT, but there is no fix MR available in Gaudi yet: https://its.cern.ch/jira/browse/ATR-26084