SkyMap surprise (Quaternions are not used in fact)

[Khudyakov Alexey]

Hello

I just found out that quaternions are not used in KStars code. Only place
where function SkyMap::toScreenQuaternion is referenced is debug code and it's
only user of quaternion related stuff.

However these unused quaternions are not free at all. Each SkyPoint contain
its quaternion representation (16 bytes wasted) and keeps it in sync which
means wasted CPU cycles. (involve relatively costly trigonometric functions)

Therefore I propose to remove quaternion-related code from KStars completely.


--
  Khudyakov Alexey
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

Hi,

On Thursday 05 November 2009 17:27:20 Khudyakov Alexey wrote:

> I just found out that quaternions are not used in KStars code. Only place
> where function SkyMap::toScreenQuaternion is referenced is debug code and
> it's only user of quaternion related stuff.
>
> However these unused quaternions are not free at all. Each SkyPoint contain
> its quaternion representation (16 bytes wasted) and keeps it in sync which
> means wasted CPU cycles. (involve relatively costly trigonometric
> functions)
>
> Therefore I propose to remove quaternion-related code from KStars
> completely.

The better solution would probably go quaternions all the way. They should be
significantly faster than the current method. I guess this is a remnant of a
first attempt that has never been completed. But that's a lot of work. So in
the meantime it is probably a waste, indeed.

Médéric
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

[Khudyakov Alexey]

В сообщении от 06 ноября 2009 01:31:49 Médéric Boquien написал:

> The better solution would probably go quaternions all the way. They should
>  be significantly faster than the current method. I guess this is a remnant
>  of a first attempt that has never been completed. But that's a lot of
>  work. So in the meantime it is probably a waste, indeed.
>
Valid point. However where do quaternions are useful? First in the projection
code. Anything else?

From what I can remember calculation of projection isn't a bottleneck in
drawing. Main time-eater is drawing itself. But without profiling I cannot say
whether I right and to which extent projection calculation is not a bottleneck
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

[Akarsh Simha-2]

On Fri, Nov 06, 2009 at 01:23:20PM +0300, Alexey Khudyakov wrote:
> ?? ?????????????????? ???? 06 ???????????? 2009 01:31:49 Médéric Boquien ??????????????:
>
> > The better solution would probably go quaternions all the way. They should
> >  be significantly faster than the current method. I guess this is a remnant
> >  of a first attempt that has never been completed. But that's a lot of
> >  work. So in the meantime it is probably a waste, indeed.

Sadly, I don't know enough to pitch in here. If it leads in an
improvement in time as shown by profiling, why not?

Regards
Akarsh
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

[Khudyakov Alexey]

В сообщении от Вторник 10 ноября 2009 19:09:14 автор Akarsh Simha написал:
> On Fri, Nov 06, 2009 at 01:23:20PM +0300, Alexey Khudyakov wrote:
> > ?? ?????????????????? ???? 06 ???????????? 2009 01:31:49 Médéric Boquien
??????????????:
> > > The better solution would probably go quaternions all the way. They
> > > should be significantly faster than the current method. I guess this is
> > > a remnant of a first attempt that has never been completed. But that's
> > > a lot of work. So in the meantime it is probably a waste, indeed.
>
> Sadly, I don't know enough to pitch in here. If it leads in an
> improvement in time as shown by profiling, why not?
>

IMO if it could be only used in toScreen it won't pay off. It slows down
SkyPoint increase memory consumption and make code more difficult to understand.
In best circumstances we could win at most few percents.

From things I could remember about quaternions (not really much) they could be
used in other places and both improve speed and code readability. I'm not sure
though.

So we should left them as they are for some time.


Here result of profiling with maximal star density (main toScreen user):

* SkyMap::toScreen eats about 10% of drawing time

* In SkyMap::toScreen ~50% of time is spent in various Options::* calls.
 So optimization of Options is viable option (in theory). Also there is no
 really much room for speed improvement with quaternions.

* Relativistic corrections are quite costly when compared to other correction
   - SkyPoint::bendlight - 11.77%
     Could be easily optimized to ~8%
   - SkyPoint::nutate  - 5.79%
   - SkyPoint::precess - 5.66%
   - SkyPoint::aberrate - 4.95%
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

[Khudyakov Alexey]

> IMO if it could be only used in toScreen it won't pay off. It slows down
> SkyPoint increase memory consumption and make code more difficult to
>  understand. In best circumstances we could win at most few percents.
>
After further examination of profiling results I can say that quaternions could
not lead to significant perfomance improvements.

SkyMap::toScreen takes ~10% of drawing time. Half of this time is subject to
optimization with quaternions. Let's say they could give 2-fold win which
means ~2.5% reduction of execution time. However overhead of keeping
quaternion in sync is ~2.5% too.

This means that quaternions should be used if and only if they lead to more
clean and concise code.
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel

[Khudyakov Alexey]

В сообщении от Вторник 10 ноября 2009 22:36:17 вы написали:
> This means that quaternions should be used if and only if they lead to more
> clean and concise code.
>
On top of all that current implementation simply doesn't work.
_______________________________________________
Kstars-devel mailing list
Kstars-devel@...
https://mail.kde.org/mailman/listinfo/kstars-devel