Board index FlightGear Development New features

Better parallelization of FlightGear?

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Better parallelization of FlightGear?

Postby AndersG » Tue Aug 31, 2010 10:58 am

Hooray wrote:So there are obviously still some opportunities for improving things in FlightGear. One thing that can already be done NOW, is running the FDM in a dedicated process. Some other things are possible, but they will require a deep understanding of concurrent systems and threading technologies.


This is not a development forum but I'll still say this: successful parallelization of software requires deep thoughts and empirical measurements about what to parallelize and what not to parallelize. E.g. JSBSim with a typical FDM configuration consumes about 1-2% CPU time on a rather slow single core. Moving that to a separate core would require a huge effort for very little gain (IMO). The key is finding the tasks that are heavy enough to benefit from more cores and structured in such a way that they can be parallelized (split into parts that can be computed in parallel).

Currently I think that rendering, the traffic manager and the emerging weather simulation system are parts that are promising with respect to parallelization. I also think that it would be preferable to first look for potential parallelism inside subsystem (while maintaining a sequential interface with the main loop) rather than trying to introduce explicit parallelism in the main loop - at the very least it will be easier to integrate.

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2465
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Enabling multiprocessor support

Postby Thorsten » Tue Aug 31, 2010 11:57 am

Currently I think that rendering, the traffic manager and the emerging weather simulation system are parts that are promising with respect to parallelization.


Most weather tasks parallelize almost trivially:

* expensive setup calls use Monte Carlo techniques - which require to run the same routine n times - whether in parallel or sequentially doesn't matter

* drifting clouds means performing position updates on a large array of objects - if that array is split into several parts which are processed in parallel or sequentially doesn't matter

and so on - the main question is if the interaction with the Flightgear core (i.e. terrain info calls or writing into the property tree) can be structured such that parallel computation is useful.
Thorsten
 
Posts: 12002
Joined: Mon Nov 02, 2009 8:33 am

Re: Better parallelization of FlightGear?

Postby Hooray » Wed Sep 08, 2010 2:39 pm

successful parallelization of software requires deep thoughts and empirical measurements about what to parallelize and what not to parallelize.

Yes, of course any parallelization efforts should be preceded by corresponding profiling, first.

E.g. JSBSim with a typical FDM configuration consumes about 1-2% CPU time on a rather slow single core. Moving that to a separate core would require a huge effort for very little gain (IMO).


I fully agree: To be honest, I really didn't mean to suggest that the FDM is necessarily a top candidate for parallelization, I don't think it is at the moment.

Instead, I was just saying that the FDM can basically ALREADY be run on a different core, outside the fgfs process space, by making use of the remote FDM possibility that has been supported by FG for a number of years now (for supporting proprietary FDMs) - and as far as I know this is -for example- also still supported by jsbsim.

This is, because there is already an explicit interface for using a "remote FDM" (i.e. see $FG_SRC/FDM/ExternalNet).

So that is already one possibility to offload -at least some- main loop work onto another core, without changing anything in FlightGear - and without explicit threading or mainloop parallelization either.

And the appealing thing about this idea is that a separate process (vs. thread) could also be run on a completely different machine. So this is already a VERY scalable design in and of itself.

Of course, given the low CPU requirements of the FDM, the FDM is not necessarily a priority - but I think it's still worth pointing this out.

For example, the benefit for jsbsim driven FDMs would be that also custom controllers (like e.g. autopilots, pid controllers) can then also be run outside the FG main loop, at more stable and more consistent rates (i.e. not framerate bound), while still being updated in FlightGear at framerate.
You mentioned now in the other thread that the autopilot issues have been sort of addressed in the latest code, so this may be less of a concern meanwhile.

The key is finding the tasks that are heavy enough to benefit from more cores and structured in such a way that they can be parallelized (split into parts that can be computed in parallel).


I absolutely agree with you, like I said above: I didn't mean to suggest that the FDM should be a priority for parallelization, my mentioning of the FDM was just meant to illustrate that this is already one possible option.

I also think that systems like rendering, the traffic manager or Nasal (in general, not just specific to weather simulation) would be perfect candidates for parallelization, with the traffic manager probably giving most bang for the buck right away, in the sense of freeing main loop resources, while still allowing AI traffic to be run.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12174
Joined: Tue Mar 25, 2008 8:40 am

Re: Better parallelization of FlightGear?

Postby MAKG » Sat Sep 25, 2010 3:13 pm

Be careful. Profiling can lead you in wrong directions.

A very common problem with poorly designed parallel algorithms is excessive mutex waits. This will show up in a profile as LOW CPU usage for the offending thread. A sign that something might be going on is unsaturated CPU usage for the process as a whole.

I just sped up my telescope simulator by at least 50% by substantially reducing the number of threads. And it made the gyroscope simulation much more predictable as well (I did this to lift a race condition).
MAKG
 
Posts: 1152
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast


Return to New features

Who is online

Users browsing this forum: No registered users and 2 guests