John Apostolakis Overview Experiences How Methods and ideas What Planning Presentation Mike Kelseys summarised experience from the major reengineering of the Bertini cascade Discussions ID: 931214
Download Presentation The PPT/PDF document "Hadronic Code Maintenance: Summary" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Hadronic Code Maintenance: Summary
John Apostolakis
Slide2Overview
Experiences
How: Methods and ideas
What = Planning
Presentation
Mike Kelsey’s
summarised
experience from the major reengineering of the Bertini cascade
Discussions
On each
approach and technical
point
Slide3Experience and methods
Methods used
in
the review / improvement of code
modules
Experiences
Strengths & limitations of approaches / techniques
Discussion topics
Lessons
Tools
- old and
new
Ideas - brainstorming
Slide4Tasks and Priorities
Needs:
What is to
be
done
Areas of concern
Different experience of developers
Common issues
Establishing priorities
Current plans (next 6-12 months)
Next priorities
F
irst
discussion
Slide5Types of Concerns
Classes with very large methods ( e.g. > 1,000 lines)
Code which has been copied and small changes made
Code adapted from Fortran
etc
Using different utility classes ( vectors, particles, …)
…
Slide6Tools for code improvement
Bertini done "by-hand",
Software
(
Eclipse has re-factoring tools, but not used
)
IgProf
- memory and CPU profiler coming from CMS - finds memory leaks, memory churn
.
Experience
For re-engineering, using it on
unit tests is
best!
Slide7Monitoring of results
Checking large
re-engineering or changes:
Add code that dumps lots of
state (
eg
by printing)
check
results before and after
each change
ANY changes of results
are reason for review or rejecting the
code changes.
Use profiler (e.g.
IgProf
)
with
‘big’ benchmarks , such as
SimplifiedCalorimeter
every ref
tag
One goal is to identify a
list of
models responsible for time, memory churn
Slide8Reducing memory churn
Memory churn = repeated allocation and
deallocation
of memory (for the same code)
Ideas for improving
Use vector
<
Obj
> instead of vector<
Obj
*> as much as possible
Pass by reference
Consider using G4Allocator – to manage small objects
Slide9Next Areas to I
mprove
Precompound
large
memory allocation seen from unit tests (priority to be confirmed)
Bertini
Most improvements already carried out
De-excitation
– evaporation
Memory churn is significant (10s MB / 1k events)
FTF
Memory churn observed
significant
recent developments, large code changes /
additions
CHIPS
Very long core methods – very hard to maintain in long term
Edge physics models being re-engineered (quasi elastic, ..)
Slide10Targets for improvement
Using alternative classes for ‘standard’ methods is a real maintenance issue
Extra code cost effort to maintain – if it can be ‘excused’ at all, it would need to have significant reasons;
Move to full use G4 particle types, four-vectors, … in code which we maintain.
How
to find what is missing ?
survey
which parts do not use four-vectors, G4 particles, hadronic exception, ..
“
grep
" for correct G4* classes/methods (will give us overview of what is not using, then discuss case by case)
Slide11Final remarks
Code maintenance is important
To improve performance (CPU, memory use)
To make code more maintainable for the future (code that is unreadable by others will not survive in the long term.)
Online notes of meeting
http://
sync.in
/
ep
/pad/view/ro.ZIcXXvm0itE/rev.2265
Start an ongoing discussion on how to improve our code (
not just today
)
Benefit from experience