1. 28 Sep, 2016 17 commits
    • Akarsh Simha's avatar
      Show global number of bad CachingDms uses · 5a9c6a42
      Akarsh Simha authored
    • Akarsh Simha's avatar
      Add profiling code to catch bad uses of CachingDms · d9ec631b
      Akarsh Simha authored
      A bad use of CachingDms would be one where a CachingDms is created or
      an angle is changed, but the cached sin/cos values are never made use
    • Akarsh Simha's avatar
      Profiling: Show caching information. · 62b1e6ac
      Akarsh Simha authored
    • Akarsh Simha's avatar
      Tests for CachingDms · da8bcf7b
      Akarsh Simha authored
      Test cases for CachingDms to check various operations.
    • Akarsh Simha's avatar
    • Akarsh Simha's avatar
    • Akarsh Simha's avatar
      Revert "Experiment 1: Can we cache trig values during first computation?" · 33b03619
      Akarsh Simha authored
      This reverts commit 11bb5cf4f213277437d7a9b503b49627fe6a0d19.
    • Akarsh Simha's avatar
      Experiment 1: Can we cache trig values during first computation? · 2d4f65a2
      Akarsh Simha authored
      Is there an improvement if we cache trig values at the cost of one
      conditional branch to see if the cache is available or not?
      The answer seems to be no! Running this code and comparing the results
      printed to the console against the previous one do not seem to
      indicate any improvement:
      DeepStarComponent::draw (322) - Spent 0.254752 seconds doing 2233550
      trigonometric function calls amounting to an average of 0.000114057 ms
      per call
      DeepStarComponent::draw (322) - Spent 0.229613 seconds doing 2233550
      trigonometric function calls amounting to an average of 0.000102802 ms
      per call
      The difference seems very insignificant. Although there might be a
      consistent trend of improvement, it is not staggering.
      I rationalize the results as follows (on Intel x86_64):
      1. If we assume that a branch mispredict takes about 10 CPU cycles
         (https://gist.github.com/jboner/2841832) and the float comparison
         takes another 10 CPU cycles, we add about 20 CPU cycles by
         introducing the branch.
      2. sin() and cos() seem to take about 55 CPU cycles each, sincos()
         taking about 210. So let's suppose 52 CPU cycles on average.
      3. Since about 50% of the trig function calls are redundant, and the
         redundant and non-redundant calls are interspersed, the branch
         predictor is very likely to mispredict.
      So this suggests that in the 50% cases where we are asked to do a
      fresh computation, we spend ~ 72 CPU cycles, whereas in the 50% cases
      where we don't need to do any computation, we spend ~ 20 CPU
      cycles. The resulting average is about 46 CPU cycles, which is not a
      significant improvement from 52 CPU cycles.
      This suggests that Experiment 2 should be as follows:
      Create an inherited class of dms called FastDms that caches
      trigonometric values every time the angle changes. So in this class,
      we basically assume that we _will_ call sin() and cos()
      eventually. Otherwise, we introduce overhead. The assumption can be
      verified by counting calls and profiling.
    • Akarsh Simha's avatar
      Optimizations in StarObject::getIndexCoords() · 5da196c1
      Akarsh Simha authored
      Avoid recomputing trigonometric functions unnecessarily
    • Akarsh Simha's avatar
      Cosmetics · e7e88e17
      Akarsh Simha authored
    • Akarsh Simha's avatar
    • Akarsh Simha's avatar
      Profiling Code: Determine time spent in EquatorialToHorizontal · 0860ef61
      Akarsh Simha authored
      While this may as well be done in callgrind, this is simple and works,
      and is less of a hassle in running KStars (doesn't slow KStars down as
      much as callgrind would).
      Under some conditions, KStars output the following:
      [24 0:15:36 D] KStars::~KStars (182) - Spent  7.86563  seconds in
      13906422  calls to SkyPoint::EquatorialToHorizontal, for an average of
       0.000565611  ms per call
      The results seem to be somewhat consistent across runs:
      Spent  2.19932  seconds in  3988240  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000551452  ms per call
      Spent  2.02403  seconds in  3464395  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000584239  ms per call
      Spent  0.261255  seconds in  332259  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000786299  ms per call
      Spent  0.464544  seconds in  530146  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000876257  ms per call
      The variations seem to be tied to the number of stars in the
      field. The first three results are from the USNO NOMAD artifact patch
      in the Sagittarius milky way region. The latter are centered around
      regions of lower star density. The variation might be probably related
      to cache performance?
    • Akarsh Simha's avatar
      Profiling Code: Count trigonometric calls on dms, and profile them. · 25b07e45
      Akarsh Simha authored
      Profiling code I: fraction of dms objects that have sin/cos called
      This is profiling code to find out what fraction of dms objects hae
      sin/cos called on them. This is useful to figure out if it makes sense
      to cache sin/cos values in the constructor itself. It turns out that
      this might not be a wise decision since the profiling results in at
      least some context says that it can be as low as 25%:
      [24 0:15:36 D] KStars::~KStars (186) - Constructed  68504224  dms
      objects, of which  17021346  had trigonometric functions called on
      them =  24.8471 %
      In a different run, it was a bit higher, but still less than 50%.
      This suggests that it might not be wise to compute and cache sin / cos
      values upon construction
      Profiling code II: determine how many trig calls on dms are redundant
      The initial results of this profiling seem to be staggering! If the
      simulation clock is running, so we are actually recomputing
      coordinates, nearly 50% of trigonometric function calls seem to be
      redundant! This might justify caching the values of sine and cosine
      upon first computation within dms() itself. This will add a
      conditional, which can lead to a potential branch mispredict, and some
      extra stuff, so I'd guess ~ 20 CPU cycles; however, it would save an
      expensive (~110 CPU cycles) trigonometric function computation almost
      50% of the time. Given that a significant fraction (~27% under some
      particular conditions) of KStars' time is spent on computing sine and
      cosine, it might be well worth it to save these calls.
      CCMAIL: kstars-devel@kde.org
    • Akarsh Simha's avatar
    • Akarsh Simha's avatar
    • Akarsh Simha's avatar
      Fix epoch problems in KStarsDateTime · 3aedbf07
      Akarsh Simha authored
      1. Use the correct definitions of Julian epoch and Besselian epoch.
      2. Create static methods to convert JD to Epoch and vice versa
      3. Create static method to convert an epoch value expressed as a
         string into a Julian Epoch number.
    • Akarsh Simha's avatar
      Fix the definition of Julian Epoch in KStarsDateTime · 90e7e720
      Akarsh Simha authored
      Since epochs are a measure of uniform flow of time, they cannot be
      affected by leap years etc.
      The peer-reviewed definition of Julian Epoch that this patch uses
      comes from Eric Weisstein's World of Science:
      (This definition may also be found on Wikipedia). The constant
      2451545.0 is identical with the #define J2000 -- i.e. the Julian date
      corresponding to the J2000.0 epoch.
  2. 27 Sep, 2016 4 commits
  3. 25 Sep, 2016 1 commit
  4. 23 Sep, 2016 1 commit
  5. 22 Sep, 2016 1 commit
  6. 21 Sep, 2016 5 commits
  7. 20 Sep, 2016 3 commits
  8. 19 Sep, 2016 2 commits
  9. 18 Sep, 2016 3 commits
  10. 17 Sep, 2016 3 commits