[Kstars-devel] Plans for threading in KStars

[Akarsh Simha]

On Sun, Oct 30, 2011 at 09:10:12PM +0400, Alexey Khudyakov wrote:
> On 30.10.2011 11:09, Akarsh Simha wrote:
> >1. Fork in StarComponent::draw() at starcomponent.cpp:284, before
> >    while( region.hasNext() )
> >
> >2. Each StarObject has a QMutex in it.
> >
> >3. Computation thread calls various computational routines (which
> >    acquire a lock on the StarObject and update the coordinates)
> >
> >4. Draw thread checks the updateID on the star and if it is not the
> >    drawID, it just waits. When updateID becomes drawID, it acquires a
> >    mutex on the star and executes drawPointSource() to draw the star.
> >
> >Further TODO: Keep computing and caching future values of positions.

Wow. I didn't intend to send this draft out to the mailing list. I'm
sorry this is very rough and incomplete :P. But anyway, that's good,
because I'm getting suggestions :D

> I'm not sure that it's possible to parallelize drawing, in
> particular OpenGL. AFAIK it uses some thread-local storage so all
> calls must be made from same thread (At least some implementations
> have such requirements).
> 
> It's quite possible that drawing couldn't be parallelized anyway.
> Since drawing primitives will be executed sequentially eliminating
> all possible benefits from threading.
> 
> Also how many threads will we get? It sounds they could count in
> thousands which shall hurt performance.

Okay, so I'm not trying to paralellize drawing. 

The slowest thing in KStars between frames (forget startup and other
things that are one-time investments) is DeepStarComponent::draw().

I profiled KStars with callgrind and I see that the most expensive
calls are StarObject::JITUpdate() and drawPointSource(). So one is the
recomputation of positions and the other is drawing. 

The other expensive call is fillToMag() (I think it's
StarBlockList::fillToMag() or something like that), but that happens
only when you slew the map. 

Both JITUpdate() and drawPointSource() take more-or-less the same
amount of time, JITUpdate() being a little faster.

So my idea is to have a worker thread that does all the computations,
calling JITUpdate() on each star, while the drawing thread paralelly
works through the same list of stars to draw them on screen. This way,
I expect we will increase the refresh rate by about 40%

So the idea is that DeepStarComponent::draw() will trigger the worker
thread to start recalculating positions (EquatorialToHorizontal() is
the slowest call), and the worker thread, after completing the update
will set StarObject::updateID to the current updateID
(KStarsData::updateID). The main thread waits in a while loop for
StarObject::updateID == KStarsData::updateID and then proceeds to draw
the star once this happens. JITUpdate being faster, at least on my
system, the compute thread should race ahead, but even otherwise,
there should be some advantage to paralellization.


> Overall I'm not sure that multithreading is good idea for KStars at
> the moment. We got quite a few crash reports lately and it takes
> time to fix them. Personally I don't like adding threading bugs (and
> we'll create some) which are harder to trace.

I agree that threading bugs will be harder to fix. I'll probably work
on this in a branch, since I'm kinda excited to try it out. It need
not be merged with master until we are in a state where we are ready
to do that.

> Did anyone profile KStars with QPainter and OpenGL backend? What are
> current bottlenecks? IIRC coordinate grid and constellation lines at
> low zoom were slowest of all.

Oh, I did not check low zoom. I checked high zoom. My major complaint
is if you zoom in on the Sagittarius milky way region with
sufficiently high star density, KStars is nearly paralyzed and each
frame takes seconds to draw. That's why I've been trying to optimize
DeepStarComponent::draw(). So at high zoom, drawing the faint USNO
NOMAD stars can be a major bottleneck, and so I'm trying to optimize
that.

Regards
Akarsh