Feature #810

Optimize computations

Added by Knödlseder Jürgen over 11 years ago. Updated almost 10 years ago.

Status:ClosedStart date:03/28/2013
Priority:NormalDue date:
Assigned To:-% Done:

50%

Category:-
Target version:1.0.0
Duration:

Description

GammaLib performs a lot of computations invoking mathematical functions (e.g. sin(), cos(), pow(), log() etc.). All these functions are time consuming, hence they should be called as few as possible.

This feature aims in optimizing the GammaLib code to speed up computations. The actions defined were derived by analyzing the code using a profiler.

Recurrence

No recurrence.

Subtasks

Action #813: Optimize GSparseMatrix::stack_push_columnRejected

Action #811: Add sin() and cos() cache to GSkyDirClosedKnödlseder Jürgen

History

#1 Updated by Knödlseder Jürgen over 11 years ago

  • Description updated (diff)

#2 Updated by Knödlseder Jürgen over 11 years ago

  • Target version set to 00-08-00

#3 Updated by Knödlseder Jürgen over 11 years ago

  • Status changed from New to In Progress

#4 Updated by Knödlseder Jürgen about 11 years ago

  • Target version deleted (00-08-00)

#5 Updated by Deil Christoph almost 11 years ago

I had a look for C / C++ benchmark frameworks and found these two:

Writing down benchmarks and running them on Jenkins would in the long run be better than “manual” optimization.
The advantages are that Jenkins results are visible for everyone and thus are an “objective” measure whether introducing optimizations into the code makes sense.

Also what is fast today (calling by const reference or caching) on some machine / compiler might not be true for most machines / compilers in 2015 - 2025, where most CTA analyses will be run, and having a benchmark suite in place that can be run simply with make benchmark will allow to evaluate GammaLib performance easily.

There’s also this new tool that allows to benchmark GammaLib from Python and track how speed changes over time:
https://github.com/spacetelescope/asv

These all look very easy to use ... I think we could make make an example gammalib-benchmark using Celero and / or hayai and / or asv in a separate repo to try it out in a day (and use it e.g. to benchmark energy resolution convolution or other things).

#6 Updated by Knödlseder Jürgen over 10 years ago

  • Target version set to 1.0.0

#7 Updated by Knödlseder Jürgen almost 10 years ago

  • Status changed from In Progress to Closed

I don’t see what should be done immediately here. Propose to close this now.

Also available in: Atom PDF