FlightGear performance ( from: How can I retire from the forum?)

[f-ojac]

+1
Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders

[Hooray]

Agreed with Adrian.

+1
Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders

I think, we simply don't have the manpower to really "produce" too many different versions - people have also been suggesting to come up with versions featuring less complex scenery/aircraft, or possibly an aircraft/scenery-specific "mod", e.g. "HeliGear" or "CombatGear". The thing is, these ideas are good in theory, but they are tying up a lot of manpower.

However, what could work is making more and more FlightGear default settings and subsystems entirely optional, so that FlightGear becomes increasingly run-time configurable - which would allow the same fgfs binary to be used for hugely different purposes. Zakalawe has been working on this as part of better run-time re-initialization, where fgcommands/Nasal APIs can be used to dynamically disable and enable whole subsystems, which are then "booted" (or shut-down) on demand. This works already for roughly a dozen of subsystems, but the real resource hogs are not yet optional.

But inspired by this discussion, I looked at the "FGCanvas" branch I started last year to see how many subsystems can be easily made optional these days. Primarily with a focus on aircraft & scenery subsystems - the idea is to put those into dedicated subsystem groups, so that resource utilization can be OPTIONALLY tracked per group. This would make it possible to overload operator new at the SGSubsystem/Group-level to track most allocations and provide /some/ stats.

And the results are pretty encouraging actually: Subject: FGCanvas Experiments & Updates

These are currently hard-coded as separate SGSubsystem instances in fg_init.cxx - even though this is conceptually a headache, simply because these should be all handled by a single SGSubsystemGroup and wrapped there.
If we were to pursure this, this would also mean that the whole shebang could also be reused for AI traffic much more easily, which is another thing that Durk & Zakalawe have been discuussing and working towards

I went ahead to see how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably.


Obviously, all aircraft related subsystems are now in their own group, and no longer show up in the main performance monitor - but performance sampling works at the subsystem-level, so can be fixed - either through a separate dialog just for aircraft related subsystems, or simply by providing a combo/dropdown menu until we have some kind of canvas treeview

Personally, I don't quite see how we could come up with different versions, binaries and packages of FG easily - but we could certainly prepare the main binary to become increasingly configurable, so that it can be used for such purposes - it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI.

[Prometeo 2013]

Well why can we use a profile systems for users like me? ...
Example..at the start a option to put all FG options in basic.
another option better grafics but a limit of 2 Gb RAM (example).
Another option more resources, almos 4 GB RAM, etc.
And finally the moster option for i7 more than 8 GB all render options on, etc

[Hooray]

Well why can we use a profile systems for users like me? ...
Example..at the start a option to put all FG options in basic.
another option better grafics but a limit of 2 Gb RAM (example).
Another option more resources, almos 4 GB RAM, etc.
And finally the moster option for i7 more than 8 GB all render options on, etc

Well, see the devel list posting that Thorsten and I previously quoted - basically, some core developers are now working towards this, which is in line with discussions we've had 4+ years ago.

But overall, the main challenge is that FlightGear was never designed to do any form of explicit memory management, as per Stuart's comments here:

Subject: Random Buildings

I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles. At one level, removing entire terrain tiles from memory earlier if memory occupancy becomes a concern would be a better management strategy than just stopping generating new buildings.

-Stuart

Even so called "smart pointers" using the RAII idiom are still a fairly recent addition to FlightGear which aren't very widely used, mainly boosted by the adoption of OpenSceneGraph (OSG) - while there were previously smart pointers in use, and a few core developers stated that they would consider any new code broken that's still using raw pointers without assigning them to smart pointers, code committed by other core developers doesn't generally have to go through any kind of peer review to be committed, which is why we're still seeing commits with raw pointers (but also subsystems/features that are unconditionally-added):

http://www.mail-archive.com/flightgear- ... 15284.html

Actually, we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. We have two classes for smart,
referencecounted pointers, osg::ref_ptr and SGSharedPtr which should be used for all long-lived, shared objects.

Thus, while the idea to scale features up/down, depending on available resources, the majority of the legacy code in FG (especially anything unrelated to OSG/rendering) would need to be explicitly re-architected to 1) track memory allocations & freeing, and to also adjust subsystems and their features accordingly.

It's not something that can be simply suggested, the code needs to know 1) how much it is using (which needs to be implemented for each supported platform), 2) where/how it is using it (specific subsystems), and 3) how to deal with situations like "not enough memory" vs. "sufficient memory: give me more features" - some data structures can be safely freed, while others would be critical for the simulator to work properly.

[Praxxus]

Trying to lighten the mood a little - perhaps this will run Flightgear ?

http://www.ebay.com/itm/Boeing-737-ng-Flight-Simulator-Fixed-for-sale-/281017346689

[punkepanda]

Trying to lighten the mood a little - perhaps this will run Flightgear ?

Cool.. Seems like it has transparent screens which auto adjust and calibrate the screen in balance with the actual light density outdoor..
That would be something to compare against ALS mode... lol

[adrian]

Even so called "smart pointers" using the RAII idiom are still a fairly recent addition to FlightGear which aren't very widely used, mainly boosted by the adoption of OpenSceneGraph (OSG) - while there were previously smart pointers in use, and a few core developers stated that they would consider any new code broken that's still using raw pointers without assigning them to smart pointers, code committed by other core developers doesn't generally have to go through any kind of peer review to be committed, which is why we're still seeing commits with raw pointers (but also subsystems/features that are unconditionally-added):

Hate to disagree about this, but smarty pointers just add complexity and inefficiency in the system. Any decent programmer knows to keep track and free memory when required. In fact there are huge C codebases, an order or two of magnitude larger than FG+OSG, that use malloc() and free() for memory management without issues. Starting to expect automatic code to do this for you just introduces bad habits imo. C++ is not Java and you can't rely on automatic garbage collection without a penalty.

[Hooray]

It's not my rule, not my discussion - in this case, I am really just rehashing what's been previously said.
Personally, I think that in the case of FG, more smart pointers would certainly not be be bad thing, but others would even consider linking in libboehm
in FlightGear terms, no dedicated memory management is worse than a theoretical performance "penalty", especially once you are leaking, because then RAM fragmentation is also likely to affect you at some point, and you may end up swapping despite having "free" RAM.

[Necolatis]

So to understand you correctly. When we have small memory /sim/tile-cache/enable should be false, else we should set to true?
Small memory in this case would be less than 4GB (32bit systems)? So for 6-8GB I should set it true?