Multi Threading Gravit

[Chris Blackburn]

Hi all,

Gerald, you may remember me from a *long* time ago when we first got
Gravit compiling on Mac OS X back in 2004 or so. Well, I rediscovered
the project a few days ago and thought I'd try and get involved with
it again!

I think the next big step is to get the program as multi threaded and
parallelised as possible. I notice that the fundamentals for this are
present in the structure of the program however when you set the
"processors" variable to a number greater than 1 the program crashes
and burns before it's managed to render a frame, well at least it does
on Mac OS X.

I think this fundamentally stems from the fact that there are chunks
of the code that are not thread safe, specifically the OpenGL
commands. You're not supposed to issue commands to a single OpenGL
context from more than 1 thread.

Before I dive in and start putting mutex locks in place for the OpenGL
commands I was wondering if you could answer one fundamental question
about the multi threaded part of the program. There seems to be a
doVideoUpdate() function call inside the frame calculation method. Is
this really needed? Or, could it be programmed such that this is only
called if running on the primary thread? This would greatly simplify
things without having to introduce mutex locks...

I'll have a play and see how it behaves but I'd also like to get your
thoughts on the subject

Regards

Chris

[Gerald Kaszuba]

Chris,

On Monday, December 27, 2010 12:35:03 AM UTC+11, Chris Blackburn wrote:

Gerald, you may remember me from a *long* time ago when we first got
Gravit compiling on Mac OS X back in 2004 or so. Well, I rediscovered
the project a few days ago and thought I'd try and get involved with
it again!

I remember! Good to hear :)

I think the next big step is to get the program as multi threaded and
parallelised as possible. I notice that the fundamentals for this are
present in the structure of the program however when you set the
"processors" variable to a number greater than 1 the program crashes
and burns before it's managed to render a frame, well at least it does
on Mac OS X.

I recently did some work on this last week actually. I forgot to push to github until today so you wouldn't have seen the changes. I decided to switch to the particle-to-particle algorithm O(n^2) to see if it still works and it runs much quicker on most simulations. This also made it easier to split the work across multiple threads. All together the recording speed was at least 5x as fast on my MacBook Pro.

The diff for it is here: https://github.com/gak/gravit/commit/6f14f411e67a6ca658ae509b4564986a24e12e50

I think this fundamentally stems from the fact that there are chunks
of the code that are not thread safe, specifically the OpenGL
commands. You're not supposed to issue commands to a single OpenGL
context from more than 1 thread.

Before I dive in and start putting mutex locks in place for the OpenGL
commands I was wondering if you could answer one fundamental question
about the multi threaded part of the program. There seems to be a
doVideoUpdate() function call inside the frame calculation method. Is
this really needed? Or, could it be programmed such that this is only
called if running on the primary thread? This would greatly simplify
things without having to introduce mutex locks...

The doVideoUpdate is really only for a single threaded method, so that the user interface doesn't lock during a recording. With threading of course, it's not necessary within frame-pp.c

I'll have a play and see how it behaves but I'd also like to get your
thoughts on the subject

If you make a fork and branch on github it would be good to see/test your work in progress :)

Gerald