Feature #1818

Investigate simulation performance in the case of large detectors

Added by pospelov over 3 years ago. Updated almost 3 years ago.

Status:ResolvedStart date:14 Jun 2017
Priority:NormalDue date:
Assignee:dmitry% Done:

0%

Category:-
Target version:Sprint 36

Description

For large detectors, like 1024x1024, the 70% of time is spent in IDetector2D::createSimulationElements (according to QtCreator/Callgrind, in Debug mode). Seems that Eigen constructor/destructors are taking most of it.

In GUI it leads to the situation, when most of the time the ProgressBar stays at the 0% (while creating simulation elements). It is not a problem per se, but it shows that we have room for improvements.

Within this item
  • Extend StandardSamples and Tests/PerformanceTest/test_performance.py to measure performance of simple simulations made on large detectors.
  • Add a small executable to Tests/Functional/Core/CoreSpecial/ to easily profile the performance in case of large detectors (similar to PolDWBAMagCylinders2.cpp or CoreIOTest.cpp)
  • Learn how to compile in Release mode with debug symbols, to be able to use Callgrind reliably.
  • Analyze the origin of the slow performance

How many instructions per cycle our processor is doing?

perf stat -a -- sleep 10

See article http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html


Related issues

Copied to BornAgain - Feature #1842: Improve simulation performance in the case of large detectors Rejected 14 Jun 2017

History

#1 Updated by pospelov about 3 years ago

  • Status changed from Backlog to Sprint
  • Target version set to Sprint 35

#2 Updated by herck about 3 years ago

  • Copied to Feature #1842: Improve simulation performance in the case of large detectors added

#3 Updated by herck about 3 years ago

  • Description updated (diff)

#4 Updated by herck about 3 years ago

  • Description updated (diff)

#5 Updated by herck about 3 years ago

  • Description updated (diff)

#6 Updated by pospelov almost 3 years ago

  • Target version changed from Sprint 35 to Sprint 36

#7 Updated by dmitry almost 3 years ago

  • Assignee set to dmitry

#8 Updated by dmitry almost 3 years ago

  • Status changed from Sprint to Resolved

Also available in: Atom PDF