Hi Matt,

Yes, I should add that info. 

This was a recon run on hps_005772.evio.0, with the command line arguments: "-L info -x /data/HPSlcsim/hps_trunk/steering-files/src/main/resources/org/hps/steering/recon/EngineeringRun2015FullRecon.lcsim -d HPS-EngRun2015-Nominal-v1 -R 5772 /data/HPS/data/hps_005772.evio.0  -DoutputFile=/data/HPS/recon.slcio”

Note that it is “only” 4242 events, which takes several hours to run due to the profiling overhead. 

The “RawTrackerHitFitterDriver” and the “EcalRawConverterDriver” use up 21% and 12% respectively, most of which is spend in a Minuit Fit. These could potentially be sped up a lot with a less general fitting algorithm that converges much faster. 

The “seedtracker.SeedTracker.process” takes up 54% of the overall CPU. As much as 20.6% of this is spend in “org.hps.recon.tracking.MultipleScattering.FindScatters”, which calls “org.hps.recon.tracking.MultipleScattering.getHelixIntersection” (20.3%) which spends most of it’s time checking if it is in a particular geometry.  But note that the call to “org.lcsim.recon.tracking.seedtracker.HelixFitter.FitCandidate", also spends 13.6% in “ org.hps.recon.tracking.MultipleScattering.FindScatters”, and similar (12.2%) for “ org.lcsim.recon.tracking.seedtracker.ConfirmerExtender.Confirm”. So our code spends a whopping 46.1% of the time stepping through the geometry to find the scatterers. I would think that this is something we can significantly simplify, since (perhaps naively) I would think that the scatterers are just the silicon. Also, as we will run GBL at the end, perhaps we don’t even need to know them quite so accurately.

I have no idea how hard it would be to do these optimizations, but they seem worth looking into.

Cheers,
Maurik





On Aug 2, 2015, at 12:00 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:

Thanks for this…very interesting!

…what sort of events did you use to create the profile?

The tracking is only ~50% of the job while I expected more (I’ve seen more, but that is without SVT & ECAL pulse fitting)…and all of the time in tracking in the MS code checking if the helix intersected the sensor!  Not that this is slow but there are lots and lots and lots of calls to org.hps.recon.tracking.MultipleScattering.getHelixIntersection and stuff it calls (checking whether the helix intersects any of the faces of the polygonal sensor).  

Considering we will (eventually, soon!) use GBL to get the fit parameters of the final tracks and we’ll just use SeedTracker for track finding, we probably don’t need to be so careful here.  

On Aug 1, 2015, at 8:07 PM, Maurik Holtrop <[log in to unmask]> wrote:

Hello All,

I have created two new pages that will be helpful if you are trying to figure out what is going on in the HPS code during reconstruction. These pages show all the methods that are called, in a tree like fashion, and indicates the number of times each method is called, and the amount of time spend executing the method. Clicking on the method name will jump you to the Java Doc for that method.

You can find the links to these pages in the Confluence “Code Documentation” section ( https://confluence.slac.stanford.edu/display/hpsg/Code+Documentation )

Best,
Maurik


Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1




Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1