Board index FlightGear The FlightGear project

Cleaning up the code

Questions about the FlightGear organisation, website, wiki etc.

Cleaning up the code

Postby Pakistan-1 » Thu Jul 09, 2015 5:21 pm

Im sure that flightgear is filled with lines of code that are not necessary anymore and are causing the simulator to be unstable and laggy
so i would like to propose that for FG 3.8 our main goal should be to optimize the simulator and make it run more smoothly and less laggy and to remove all the "junk" that has collected in the past 18 years
User avatar
Pakistan-1
 
Posts: 499
Joined: Tue Jun 18, 2013 2:49 am
Location: Hong Kong
Callsign: DocDMG,PK1,MIA2020
Version: 3.7
OS: Windows 10

Re: Cleaning up the code

Postby clrCoda » Thu Jul 09, 2015 5:34 pm

HAHAHAHAHA! lol rofl
Ray St. Marie
clrCoda
 
Posts: 1228
Joined: Wed Apr 07, 2010 11:04 am

Re: Cleaning up the code

Postby legoboyvdlp » Thu Jul 09, 2015 7:35 pm

I am rolling on the floor! Of course, Pakistan, you have looked at the code to see the junk collected, and of course the developers don't bother cleaning it. Go learn C++ and do it yourself. Take a look to see how much junk there is.
User avatar
legoboyvdlp
 
Posts: 7325
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: next
OS: Windows 10 HP

Re: Cleaning up the code

Postby Johan G » Thu Jul 09, 2015 7:42 pm

Though seriously, even as I know it is very unlikely, I have now and then been wishing that FlightGear would at some time have a release cycle purely aimed at refactoring and improving documentation, maybe even adding starting to add unit tests to the code base. Unfortunately, as I said, it is very unlikely.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5546
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Cleaning up the code

Postby hamzaalloush » Thu Jul 09, 2015 8:27 pm

It's easier to knock the person than ask him why he thinks that... so what makes you think that? what kind of "junk" are talking about?
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Cleaning up the code

Postby Philosopher » Thu Jul 09, 2015 9:10 pm

He's probably talking about comments – those need to be removed for sure. :P
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Cleaning up the code

Postby Johan G » Thu Jul 09, 2015 9:15 pm

Philosopher wrote in Thu Jul 09, 2015 9:10 pm:...those need to be removed for sure. :P

Noo, not the comments! That's the part of the code I can read for sure.* ;)

* Though some are too cryptic for a non-coder.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5546
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Cleaning up the code

Postby Hooray » Thu Jul 09, 2015 10:57 pm

Pakistan-1 wrote in Thu Jul 09, 2015 5:21 pm:Im sure that flightgear is filled with lines of code that are not necessary anymore and are causing the simulator to be unstable and laggy
so i would like to propose that for FG 3.8 our main goal should be to optimize the simulator and make it run more smoothly and less laggy and to remove all the "junk" that has collected in the past 18 years


are you familiar with coding, are you familiar with C++, are you familiar with SG/FG ?
Do you know anything about optimizing software, do you understand how to benchmark performance ?

Don't get me wrong, the suggestion of having dedicated "optimizing" (or "bug fixing") release cycles isn't new - but what you wrote above, doesn't sound overly informed unfortunately. For example, old/legacy code doesn't necessarily translate into performance issues, equally, new code doesn't automatically improve performance. There are a number of examples proving the opposite.
In general, you would be well advised to look at a number of wiki articles to understand how the project works, and how your ideas can be turned into "features".
If you are serious about your suggestion, it would make sense to learn how to benchmark/profile FG - there are a number of built-in tools available (performance monitor, osg on-screen stats, Nasal systime() profiling, built-in profiler).
You don't even need to build FG from source to do this (even though being able to build FG from source would definitely come in handy).
Very soon, you will understand that "dead code" doesn't necessarily affect FG performance at all (in fact, dead code is usually not even running - by definition).
Equally, you will find that there are many inter-dependent factors affecting overall performance, including startup/run-time settings, and different subsystem configurations.
If you are concerned about "lag", you will primarily want to look at things like CPU, GPU and RAM load/occupancy - ideally, per subsystem - and that will greatly vary, depending on your actual startup/runtime settings.

One of the things that is going to help with this in the long-term is the HLA effort, because it will help partition FG into dedicated modules, running in separate threads/processes that can be more easily benchmarked in terms of CPU/GPU and RAM load - especially when compared to doing this for a monolithic executable.

Then again, it seems like you may have to do lots of reading and experiments before looking into this any further.

Here are a few related pointers:

http://wiki.flightgear.org/Howto:Use_the_system_monitor
http://wiki.flightgear.org/Built-in_Profiler

http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing
http://wiki.flightgear.org/FlightGear_Headless
http://wiki.flightgear.org/Subsystem-le ... FlightGear

http://wiki.flightgear.org/Initializing_Nasal_early
http://wiki.flightgear.org/High-Level_Architecture
http://wiki.flightgear.org/FlightGear_h ... re_support

Let me know, if you'd like to have more - but as you can surely see by now, this is not a trivial undertaking, and it depends on having a suite of tests/benchmarks to evaluate different aspects of the simulator (e.g. CPU/GPU and RAM) under different circumstances.

Like others have mentioned, it would be good to have more unit tests, but also more internal stats exposed to the property tree - to help with profiling/benchmarking and debugging FG.

Depending on your background/interests, there are several things that could be done to get this started - one of the lower hanging fruits being SIGAR support via cppbind: http://wiki.flightgear.org/Nasal/CppBind

Absent something like that, you would need to have tons of background/internals knowledge on how SG/FG work internally, and couldn't draw any reliable conclusions otherwise.

Finally, one of the main factors involving frame spacing (latency) is the Nasal GC (garbage collector) for many people/platforms, for details see: http://wiki.flightgear.org/How_the_Nasal_GC_works
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: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: Cleaning up the code

Postby japreja » Sat Jul 11, 2015 7:19 pm

The main thing that bugs me about the code is indentation, other than that I thought most compilers with optomization options cleaned up the binaries prety well automaticaly...

Johan G wrote in Thu Jul 09, 2015 9:15 pm:
Philosopher wrote in Thu Jul 09, 2015 9:10 pm:...those need to be removed for sure. :P

Noo, not the comments! That's the part of the code I can read for sure.* ;)

* Though some are too cryptic for a non-coder.

lol, I agree. if every coder wrote comments to all their code it would be quite an educational experiance to read. I rarely comment my code, unless I intend to distribute it to the masses. Even then, not many read them. non FG related example of my code (diagrams look to be mangled by their forum software migration) :(
japreja
 
Posts: 331
Joined: Thu May 07, 2015 11:05 pm
Location: MT, USA
OS: Windows 10 Pro 64bit

Re: Cleaning up the code

Postby Hooray » Sat Jul 11, 2015 7:29 pm

while dead-code is usually identified and eliminated rather easily (DCE), algorithmic issues will not be automagically addressed by a compiler's middle-end.
However, FG isn't exactly deterministic, so if FG is CPU or GPU bound depends greatly on your hardware and your actual settings.
Then again, certain components are infamous for having a rather significant impact on frame rate/frame spacing. However, those are not magically optimized by the compiler - you can see just how fast FG can run by using the "minimal startup profile" (as per the wiki):

http://wiki.flightgear.org/Troubleshoot ... up_profile
Image

The whole point of this exercise is to start up a bare/minimal version of FG with most features disabled, to end up with a baseline/benchmark for determining the effect of certain settings and features.

Equally, a few core developers are working towards a "headless" mode, with even the graphics entirely disabled: http://wiki.flightgear.org/FlightGear_Headless
Image

At some point, a few core developers were also contemplating to establish a *nix like boot design with different "run-levels" to more easily exclude certain components/systems and have a handful of incremental run-levels: http://wiki.flightgear.org/FlightGear_Run_Levels
Image

It is this kind of work that is needed to draw conclusions about performance and potential optimizations, and this will be greatly facilitated by adopting HLA and migrating FG towards a RTI/HLA architecture, where subsystems may end up in their own threads/processes for better troubleshooting/debugging and profiling.

And this kind of work will also help re-targeting FG, e.g. for mobile/gaming platforms: http://wiki.flightgear.org/Howto:Optimi ... le_devices
or for much older hardware: http://wiki.flightgear.org/FlightGear_and_old_Hardware

And this would at some point also make benchmarks and feature-scaling possible:
http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Feature_Scaling

Personally, I am not convinced that people should explore optimizing FG without first understanding a few basics first, i.e. referring to the pointers I posted earlier.
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: 11469
Joined: Tue Mar 25, 2008 8:40 am


Return to The FlightGear project

Who is online

Users browsing this forum: Applebot [Bot] and 1 guest