<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 13, 2013 at 6:04 PM, Akarsh Simha <span dir="ltr"><<a href="mailto:akarshsimha@gmail.com" target="_blank">akarshsimha@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">

> AFAIR conversions of coordinates is not worst bottleneck. Last time I checked (1<br>
> or 2 years ago) drawing of constellation lines and borders and coordinates grid<br>
> very much to my surprise. Any proposals to improve performance must be backed up<br>
> with profiling/benchmarks. Otherwise it's too easy to fall into trap of<br>
> optimizing wrong thing.<br>
<br>
</div>Even with the USNO NOMAD catalog? That is a bit hard to believe,<br>
although it might be the case. With the USNO NOMAD catalog, KStars<br>
crawls when zoomed in on Sagittarius.<br></blockquote><div><br></div><div>I'm using NOMAD and I've attached some graphs from VTune. Note that they are all red, since we only ever use one core, of the four available on my machine.</div>

<div><br></div><div>I tested them by running opening KStars and maximizing the number of displayed stars, and then slewing back and forth (with no hidden objects during slewing): <a href="http://i.imgur.com/BVxGi96.jpg">http://i.imgur.com/BVxGi96.jpg</a></div>

<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="im">> Furthermore we can get ~10x performance boost (uneducated guess) by changing<br>
> representation of sky point. Currently it's represented by two angles and<br>
> conversions between different coordinate systems are quite costly: 5 or 6 calls<br>
> to trigonometry functions.<span class="" style="color:rgb(34,34,34)"> </span></div></blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">
> Much more convenient scheme is to store points as 3D vectors with unit norm and<br>
> some flag to distinguish between coordinate systems. In this case<br>
> transformations between different coordinate systems could be done using<br>
> quaternions and are cheap (15 multiplications). So there are no reason to cache<br>
> horizontal coordinates, they could be recalculated on the fly if desired.  Most<br>
> of the projections also become cheaper since they don't involve trigonometry in<br>
> this representation.<br>
><br>
><br>
> This has been discussed on mail list before. You can search using "quaternion"<br>
> keyword<br>
<br>
</div>Yeah, quaternions are certainly a good idea. Not sure Henry can fit it<br>
into his time-line?</blockquote><div><br></div><div>Yes, especially since in addition they let you work with float4, which is much faster anyways than float1. However, moving to quaternions would be a side-effect of moving to OpenCL, since moving to CL means moving to quaternions.</div>

</div></div></div>