Project

General

Profile

Geant4 EM Physics Code Review Weekly Phone Meeting

Meeting

Date: August 9, 2013 at 10.00 AM US CDT (Fermilab local time)
Place: 1-866-740-1260 (ReadyTalk line) (Host : Boyana Norris)

Participants:

Andrea Dotti
Krzysztof Genser
Boyana Norris
Soon Yung Jun

Discussion (Summary by Krzysztof)

Boyana is able to access all the website resources now.
We should try to get the rest of the the group to be able to do the same.
see how to get an account at https://fermi.service-now.com/kb_view.do?sysparm_article=KB0010788
also see fermilab kerberos and fermilab linux-users list archives for hints related to kerberos etc...

Soon was looking at the G4Physics2DVector class:

Is idx variable caching needed/done?

Andrea mentioned that Vladimir made changes to 2D vector recently to make it MT compliant (removing caching).
We are not sure why the idx variables are they way they are there now.

Soon suggested to replace the vectors of doubles with the vectors of floats (also in G4PhysicsVector).
We agreed that doing the tests is a good idea. Soon will do them. We'll decide on next actions once we know the impact of the changes.

We are going to suggest making the internal data container of G4PhysicsVector to be read only.
In order to do this we'll need to break its parent class relationship to
G4PhysicsOrderedFreeVector (and re-implement G4PhysicsOrderedFreeVector to have its own container)
but it should be worth the effort to enable data sharing in the MT version.

We discussed the fact that changing the internal data container of G4PhysicsVector had an impact
on how often CLHEP::MTwistEngine::flat is seen on the leaf of the stack. See:
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07_SimplifiedCalo_01/e-.FTFP_BERT.50.0/prof_big_functions_leaf_frac_list_01.html
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07a_SimplifiedCalo_01/e-.FTFP_BERT.50.0/prof_big_functions_leaf_frac_list_01.html

In order to understand it better Soon added big functions path/leaf count tables to the profiling pages (as suggested to us by Marc P),
see e.g.:
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07_SimplifiedCalo_01/e-.FTFP_BERT.50.0/prof_big_function_paths_count_list_01.html
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07a_SimplifiedCalo_01/e-.FTFP_BERT.50.0/prof_big_functions_path_count_list_01.html
Or other tables from:
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07_SimplifiedCalo_01/e-.FTFP_BERT.50.0/ or
https://oink.fnal.gov/perfanalysis/g4p/g4p_9.6.r07a_SimplifiedCalo_01/e-.FTFP_BERT.50.0/

Boyana suggested to see if gcc has not inlined CLHEP::MTwistEngine::flat more in the new case. To check that Soon will profile
g4p_9.6.r07 and g4p_9.6.r07a with gcc option -O0
Soon will also profile g4p_9.6.r07 with -O1, -O2, -O3 to see what effect the optimization has on various functions.

We may want to ask ask CLHEP people to inline CLHEP::MTwistEngine::flat if we see it making an effect.

Boyana will investigate inlining of CLHEP::MTwistEngine::flat with hpctoolkit (using simplifiedCalo)

Andrea will send his old results regarding the effects of the optimization.
He will also take a look at G4VEMProcess to guide our discussion regarding it next week.

We'll talk again next week at 10 Central
Krzysztof will try to get a ReadyTalk number to have an alternative one.