[Kstars-devel] Kstars optimization

[Jason Harris]

Hi Prasanna,

Prasanna Krishnamoorthy wrote:
> First off, thanks to Jason and all the others who've contributed to
> make Kstars a brilliantly useful tool. If you've not heard of this
> before, I'm sure you'd be pleased to know that Kstars is part of the
> syllabus for students in Kerala, a state in South India. It's a part
> of the curriculum to help teach both astronomy and encourage and teach
> students to use computers.
> 
That's really great to hear!  I wasn't aware of it.

> As part of this, I'm trying to get Kstars to run on the cheapest
> machines possible - we're targeting 1GHz processors. Preliminary
> results show us that there needs to be a bit of optimization before we
> can bring Kstars to a usable level.
> 
If you want a "quick and dirty" optimization that you can implement 
without changing any code, simply reduce the number of objects.  If you 
cut the star catalog at 40,000 objects (by removing 
hip041.dat-hip127.dat), you'll remove almost 100,000 objects, and these 
are very faint stars (all stars beyond the 40,000 mark are fainter than 
8th magnitude, and the full catalog to 126,000 stars only goes to 9th mag!)

Actually, the program might complain if you simply remove these files, 
so you can either modify the NHIPFILES value in kstarsdata.h, or you can 
  delete all the lines in each file above hip040.dat, but delete all of 
the lines in these files.

This could be used as a temporary measure while real optimizations are 
being pursued.  Or you might find that doing this (and fixing the issues 
with plastik) is enough to make it run acceptably on your hardware.

> I also did some preliminary profiling with oprofile and kcachegrind,
> and the results were surprising! The most time(~50%) is spent in
> plastik.so, 
This is really surprising, especially since the main window has hardly 
any GUI elements!  What happens if you profile while using a style other 
than plastik?  My guess is there must be something wrong here that has 
nothing to do with KStars.

> which I presume is the drawing and updation. The next
> largest amount of time(~20%) was spent in
> skypoint.cpp:EquatorialToHorizontal, in just three lines -
>        AltRad = asin( sinAlt );
>        cosAlt = cos( AltRad );
> and
>        else AzRad = acos( arg );
> 
Yes, the program indeed spends a lot of its time calculating the 
horizontal coordinates (azimuth and altitude) of objects in the sky.  I 
don't think it's doing any of these unnecessarily, but maybe it doesn't 
need to be done for every timestep, especially at lower zoom settings.

> You can check for yourself, I've attached the oprofile output which
> you can directly use with kcachegrind.
> 
> So couple of ideas I had to speed things up - a) implement a faster
> trig library, b) use a (large) look-up table for the trig function
> (trade-off space/time).
> 
> The first one seems hard - primarily because the gnu libm trig
> libraries seem to be among the best in the first place :-).
> 
Agreed :)

> The second should be quite doable and give us a large boost, however,
> I'm worried about the level of accuracy required in kstars, and
> whether say a 10K point LUT for each of the trig functions with linear
> interpolation would be very seriously detrimental to accuracy.
> 
I've thought about this in the past.  It may be worth trying.  Again, at 
low zoom level extreme trig accuracy is probably unnecessary in most 
cases.  There will be situations when we want the real trig values, but 
in most cases, an interpolated grid should be good enough.

A slight improvement over a static lookup table over the full range of 
angles is to dynamically create lookup table values for the range of RA 
and Dec values that are currently being displayed.  The advantage is 
that you can get a grid resolution that changes with zoom level, so it 
is always a good match to the pixel resolution.  The disadvantage is 
that it's more complicated, and you might need 4 lookup tables (for the 
displayed ranges in RA, Dec, Az and Alt).

> Of course, SIMD and other optimizations would also really boost the
> performance (we have mmx/sse in these processors). But I don't think
> the code is written with that kind of optimization easily possible,
> 
> Thanks in advance,
> Prasanna.
> 
Thanks a lot for the feedback.  Just so we can be clear of your intent, 
are you saying that you want to try implementing a lookup table, or are 
you just advocating the idea of doing so?

regards,
Jason