[Kstars-devel] Kstars optimization

[Prasanna Krishnamoorthy]

Hello all,

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.

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.

Since you guys must be knowing how to improve performance, I would be
very grateful to hear from you.

We're running ubuntu dapper, with Kstars 3.5.2.  Edgy is not preferred
because we like LTS :-), and 5 years of patches.

I also did some preliminary profiling with oprofile and kcachegrind,
and the results were surprising! The most time(~50%) is spent in
plastik.so, 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 );

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 :-).

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oprof.out.kstars.gz
Type: application/x-gzip
Size: 36686 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20061128/bbbf463b/attachment-0001.gz