Re: [Flightgear-devel] multi-threading / CPU usage

2008-10-04 Thread Vivian Meazza
James Turner wrote

 On 3 Oct 2008, at 13:48, Matthew Tippett wrote:
 
  Speaking of which, another call out for multithreading...  The GPU
  isn't the limiting factor in our tests, the CPU is.  Even mid-low end
  systems have 2-4 cores these days, and with the multi-display demo we
  are continually capped by one CPU.
 
 I have a long, long, long term plan to improve multi-threading
 support, by enforcing subsystems to *only* communicate via the
 property tree, which has light-weight locks thanks to some work by
 Mathias. With a dependency graph between subsystems (which I want to
 add for other reasons any way) it would then become possible to run
 any 'clean' subsystem on a pool of worker threads (maybe just one,
 maybe more).
 
 I'm sure there's some other locking that would be required for global
 state (eg, the AIManger objects), and of course there's awkward cases
 that will never be clean (especially instruments that touch the scene
 graph) but it still seems a worthwhile goal. It'd be worth identifying
 which subsystems are the big time sinks (FDM? AItraffic?) to
 prioritise this.
 
 Another thing that would work well is to proxy all nasal script
 invocations to a Nasal helper thread - again this assumes scripts
 basically interact with the sim via properties (which they already do)
 and that any system functions they call are thread safe - not very
 hard to do. As more and more functions get moved to nasal, this might
 become a very easy way to balance the CPU usage.
 

I recently profiled CVS-Head compiled under MSVC9 - before and after the
new Nasal. Before, Nasal was the tall pole in the tent - by a long, long
way. Discussing this with Melchior and Andy, the consensus was that this was
caused by a rogue script. Despite much binary searching, I never managed to
track it down, except to say that the problem started around 12th Aug.
After, the situation was more normal, with malloc and groundcache being top
of the list, but not by very much. The Nasal hash function is coming up on
the rails, perhaps there is still a rogue script around. I would be wary of
adding too much more Nasal without resolving this.

When you feel inclined to take this work further, I can produce a new
profile in perhaps half a day. Just ask.

Vivian



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] multi-threading / CPU usage

2008-10-03 Thread James Turner

On 3 Oct 2008, at 13:48, Matthew Tippett wrote:

 Speaking of which, another call out for multithreading...  The GPU
 isn't the limiting factor in our tests, the CPU is.  Even mid-low end
 systems have 2-4 cores these days, and with the multi-display demo we
 are continually capped by one CPU.

I have a long, long, long term plan to improve multi-threading  
support, by enforcing subsystems to *only* communicate via the  
property tree, which has light-weight locks thanks to some work by  
Mathias. With a dependency graph between subsystems (which I want to  
add for other reasons any way) it would then become possible to run  
any 'clean' subsystem on a pool of worker threads (maybe just one,  
maybe more).

I'm sure there's some other locking that would be required for global  
state (eg, the AIManger objects), and of course there's awkward cases  
that will never be clean (especially instruments that touch the scene  
graph) but it still seems a worthwhile goal. It'd be worth identifying  
which subsystems are the big time sinks (FDM? AItraffic?) to  
prioritise this.

Another thing that would work well is to proxy all nasal script  
invocations to a Nasal helper thread - again this assumes scripts  
basically interact with the sim via properties (which they already do)  
and that any system functions they call are thread safe - not very  
hard to do. As more and more functions get moved to nasal, this might  
become a very easy way to balance the CPU usage.

James


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] multi-threading / CPU usage

2008-10-03 Thread Matthew Tippett
Are there any short term targets that will show benefit?

Regards,

Matthew


 Original Message  
Subject: [Flightgear-devel] multi-threading / CPU usage
From: James Turner [EMAIL PROTECTED]
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net
Date: 03/10/08 09:51 AM

 On 3 Oct 2008, at 13:48, Matthew Tippett wrote:
 
 Speaking of which, another call out for multithreading...  The GPU
 isn't the limiting factor in our tests, the CPU is.  Even mid-low end
 systems have 2-4 cores these days, and with the multi-display demo we
 are continually capped by one CPU.
 
 I have a long, long, long term plan to improve multi-threading  
 support, by enforcing subsystems to *only* communicate via the  
 property tree, which has light-weight locks thanks to some work by  
 Mathias. With a dependency graph between subsystems (which I want to  
 add for other reasons any way) it would then become possible to run  
 any 'clean' subsystem on a pool of worker threads (maybe just one,  
 maybe more).
 
 I'm sure there's some other locking that would be required for global  
 state (eg, the AIManger objects), and of course there's awkward cases  
 that will never be clean (especially instruments that touch the scene  
 graph) but it still seems a worthwhile goal. It'd be worth identifying  
 which subsystems are the big time sinks (FDM? AItraffic?) to  
 prioritise this.
 
 Another thing that would work well is to proxy all nasal script  
 invocations to a Nasal helper thread - again this assumes scripts  
 basically interact with the sim via properties (which they already do)  
 and that any system functions they call are thread safe - not very  
 hard to do. As more and more functions get moved to nasal, this might  
 become a very easy way to balance the CPU usage.
 
 James



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] multi-threading / CPU usage

2008-10-03 Thread James Turner

On 3 Oct 2008, at 15:14, Matthew Tippett wrote:

 Are there any short term targets that will show benefit?

That's a question best answered by profiling and measurement, since  
people are notoriously bad at guessing such things.

The 'Nasal on a helper thread' thing may be possible in the short  
term, if someone wanted to look at it, but whether or not Nasal is  
using a noticeable amount of CPU is highly debatable, and depends a  
lot on the particular aircraft / models you test with, I expect.  
Again, profiling and concrete numbers are needed before doing  
potentially intrusive changes for performance's sake.

In general, FG has quite a few data dependencies internally which make  
multi-threading challenging right now - there's groundwork to make the  
data-dependencies more explicit (i.e, via the property tree) that has  
to happen before pieces can easily move to other threads.

Ensuring that as much rendering work happens on other threads (OSG can  
be very aggressive about this) is a likely area of investigation, but  
one I'll leave to Tim. In theory OSG can be doing DB paging, model and  
texture loading, updates and culls on worker threads, and the actual  
drawing on another. I have no notion how much of that is happening  
with the current code. My guess would be that pieces ported from PLIB/ 
SSG may not be playing 'nice' with the aggressive OSG pipe-lining, but  
equally, updating those pieces of code to be more OSG friendly isn't a  
quick hack either.

James


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] multi-threading / CPU usage

2008-10-03 Thread Vivian Meazza
James Turner wrote

 On 3 Oct 2008, at 13:48, Matthew Tippett wrote:
 
  Speaking of which, another call out for multithreading...  The GPU
  isn't the limiting factor in our tests, the CPU is.  Even mid-low end
  systems have 2-4 cores these days, and with the multi-display demo we
  are continually capped by one CPU.
 
 I have a long, long, long term plan to improve multi-threading
 support, by enforcing subsystems to *only* communicate via the
 property tree, which has light-weight locks thanks to some work by
 Mathias. With a dependency graph between subsystems (which I want to
 add for other reasons any way) it would then become possible to run
 any 'clean' subsystem on a pool of worker threads (maybe just one,
 maybe more).
 
 I'm sure there's some other locking that would be required for global
 state (eg, the AIManger objects), and of course there's awkward cases
 that will never be clean (especially instruments that touch the scene
 graph) but it still seems a worthwhile goal. It'd be worth identifying
 which subsystems are the big time sinks (FDM? AItraffic?) to
 prioritise this.
 
 Another thing that would work well is to proxy all nasal script
 invocations to a Nasal helper thread - again this assumes scripts
 basically interact with the sim via properties (which they already do)
 and that any system functions they call are thread safe - not very
 hard to do. As more and more functions get moved to nasal, this might
 become a very easy way to balance the CPU usage.
 

I recently profiled CVS-Head compiled under MSVC9 - before and after the
new Nasal. Before, Nasal was the tall pole in the tent - by a long, long
way. Discussing this with Melchior and Andy, the consensus was that this was
caused by a rogue script. Despite much binary searching, I never managed to
track it down, except to say that the problem started around 12th Aug.
After, the situation was more normal, with malloc and groundcache being top
of the list, but not by very much. The Nasal hash function is coming up on
the rails, perhaps there is still a rogue script around. I would be wary of
adding too much more Nasal without resolving this.

When you feel inclined to take this work further, I can produce a new
profile in perhaps half a day. Just ask.

Vivian



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel