Board index FlightGear The FlightGear project

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

Questions about the FlightGear organisation, website, wiki etc.

Re: How can I retire from the forum?

Postby f-ojac » Mon Jul 07, 2014 6:41 pm

+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 ;-)
--
If you want to support my Terrasync server, hosted on a private server, you can donate here: http://ns334561.ip-5-196-65.eu/WS2.0/WS ... 2.0.1.html
f-ojac
 
Posts: 1276
Joined: Fri Mar 07, 2008 9:50 am
Version: GIT
OS: GNU/Linux

Re: How can I retire from the forum?

Postby Hooray » Mon Jul 07, 2014 6:53 pm

Agreed with Adrian.
f-ojac wrote in Mon Jul 07, 2014 6:41 pm:+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
Hooray wrote:
Hooray wrote in Sun Jul 06, 2014 6:55 pm: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.
Image

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 :D


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.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby Prometeo 2013 » Mon Jul 07, 2014 7:16 pm

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
Prometeo 2013
 
Posts: 22
Joined: Wed Jun 18, 2014 11:43 am
Callsign: Prometeo2013
OS: windows 8.1

Re: How can I retire from the forum?

Postby Hooray » Mon Jul 07, 2014 7:33 pm

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
stuart wrote: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
Tim Moore wrote: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.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby Praxxus » Mon Jul 07, 2014 7:53 pm

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
Core i5 6600k @ 3.5GHz ; ASUS TUF MARK2 Motherboard
Corsair Vengeance LPX 16GB PC4-19200 2400MHz ; H100i GTX Liquid CPU Cooler ; Palit GeForce GTX980Ti S/Jetstream ; Corsair RM850X ; 250Gb m.2 Drive ; 2x120Gb HyperX FURY SSD's 500r/500w ; Vortex case
Praxxus
 
Posts: 70
Joined: Fri Mar 01, 2013 11:19 pm
Location: EGHH
Callsign: Porcius, G-BMTH
IRC name: Porcius
Version: 2018.3.2
OS: Winderz 10 x64

Re: How can I retire from the forum?

Postby punkepanda » Mon Jul 07, 2014 8:25 pm

Praxxus wrote in Mon Jul 07, 2014 7:53 pm: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
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: How can I retire from the forum?

Postby adrian » Mon Jul 07, 2014 8:48 pm

Hooray wrote in Mon Jul 07, 2014 7:33 pm:

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.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: How can I retire from the forum?

Postby Hooray » Mon Jul 07, 2014 9:00 pm

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.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear performance ( from: How can I retire from the

Postby Necolatis » Mon Jun 29, 2015 2:50 am

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?
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 1999
Joined: Mon Oct 29, 2012 12:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2019.1.2
OS: Windows 10

Previous

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest