Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "High-Level Architecture"

From FlightGear wiki
Jump to: navigation, search
Line 4: Line 4:
  
 
Using a HLA, computer simulations can interact with other computer simulations regardless of the computing platforms. The interactions between the simulations are managed by a ''Run-Time Infrastructure'' (''RTI'').
 
Using a HLA, computer simulations can interact with other computer simulations regardless of the computing platforms. The interactions between the simulations are managed by a ''Run-Time Infrastructure'' (''RTI'').
 +
 +
{{FGCquote|1= Moving toward a new modular HLA architecture offers a number of possibilities. One of these is that different modules, or subsystems, can effectively become independent binaries. |2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34196458/  | title  = <nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>  | author = <nowiki>Durk Talsma</nowiki>  | date  = Jun 11th, 2015  }}}}
  
 
{{FGCquote
 
{{FGCquote

Revision as of 14:03, 15 November 2015

High-Level Architecture (HLA) is a general purpose architecture for distributed computer simulation systems.

Using a HLA, computer simulations can interact with other computer simulations regardless of the computing platforms. The interactions between the simulations are managed by a Run-Time Infrastructure (RTI).

Cquote1.png Moving toward a new modular HLA architecture offers a number of possibilities. One of these is that different modules, or subsystems, can effectively become independent binaries.
— Durk Talsma (Jun 11th, 2015). Re: [Flightgear-devel] Policy Document and V4.X Roadmap.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Ever heard about how the firefox/google chrome browsers are hoping to better leverage multicore systems by using a separate process for each website (tab) ?

That's basically in line with how FlightGear is going to work once HLA materializes a little more.

The main problem here is that most "legacy" software (like FlightGear) was originally written for a computer with a single processor (CPU).

These days however, it is common for a computer to have multiple processors, with each having multiple cores. Nowadays, it is hard to come across new computers that have <= 4 cores. Which basically means that there are 4 CPUs that can handle operations independently. Imagine it like having a car (or airplane!) with 4 engines, while the "driver" (you) only knows how to operate a single engine.
However, old software was written for a single processor, typically using a single main loop that assumes there's a single FAST processor. Which is why people would see better frame rates whenever they upgraded their CPU. This basically means that FlightGear would typically be CPU-bound (limited by the speed of the CPU, that is supposed to hand over jobs to the GPU).


— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Given the multicore revolution, what people have been doing typically is to use separate threads for certain, well-defined, tasks - such as running a dedicated thread for sound or for loading AI models.

In addition, OSG itself does have fairly extensive multithreading support as long as its coding patterns and protocols are used, so that OSG can internally decide which part of the job it can render asynchronously, on another core.

But otherwise, FlightGear's main loop still is built around the "single-CPU" concept, which is why there is a ton of stuff done in the main loop that could be done separately at some point, which would free up resources for better frame rates/latencies. The other issue with conventional threading is that threading is fairly low-level, it is very easy to write code that works ~80% of the time and crashes ~20% of the time (or vice versa). Processes are easier to understand than threads, and it is far more difficult to crash the main process - simply because a process doesn't typically have access to internal data structures. That is however also a problem because each FlightGear process needs a way to talk to the main process and invoke commands, get data etc - that is why some kind of inter-process communication is needed (IPC).


— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png HLA is a fancy message-bus framework where each component (=called a "federate") can talk with other components across a bus called a REAL-TIME INFRASTRUCTURE (RTI) using an IPC framework that works across sockets and/or shared memory.
— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png In non-coding terms this means that FlightGear currently works such that FlightGear is a "single person" doing a well-defined job (which is HUGE, it's basically a list of 10000 things each frame) - for some tasks, there are "helpers" (=other people) that can help with certain tasks, such as doing sound processing for example - but usually, there's a single entity responsible for processing the main loop.


The "problem" is that modern computers provide a "team" of people and Flightgear in its current form doesn't really know how to leverage this "team" (of processors/cores) efficiently, so depending on your hardware, 60-70% of your CPU resources may be sitting "idle" - waiting for work that FlightGear doesn't know how to assign.

While there are some ways to add more team members to the existing FG "group", the next issue is that work needs to be coordinated, or the whole thing will "explode" sooner or later due to sheer chaos, because someone (on your team) is doing something that the other one is unaware of, which is a violation - and which triggers a segfault/crash, i.e. your operating system is watching your "team" of FG people/CPUs and once it sees that the "flightgear team" is doing something crazy, it simply kills the whole team because it didn't behave properly  :D

Equally, the OS may decide to kill FG because it doesn't manage memory properly


— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png So what core developers are working towards is looking at the existing FlightGear main loop, to come up with a list of things/tasks that can be done asynchronously, i.e. in parallel with other tasks - once that list is complete, people are looking at what each "team member" needs in terms of "data" and "functionality" - e.g. some team members may only need to access the sound systems, others need to access the property tree, the AI system, the FDM and so on.


The next thing is that core developers need to come up with a bunch of interfaces (so called APIs) that can be provided/used by each "team member" (task/federate). At that point, it's mainly a matter of wiring up each team member and letting them form a so called "federation" of workers. All of a sudden the main loop would become fairly lightweight and all the non-rendering tasks would be handled by "coworkers".


— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The added advanatge here is that there's a per-process memory limit, and there will be left more RAM for people on 32 bit OS because each process will have its own address space - equally, debugging/profiling and troubleshooting FlightGear will become easier because individual components can be tested, without having to fire up the whole thing.

Also, FlightGear is currently written primarily in C++ - once HLA/RTI is in place, future components could be developed using other languages, such as Python, Java or Ada for example.

(HLA is partially supported (as a multiplayer protocol substitute) already. But the way core developers are hoping to use HLA is to split up the simulator into a bunch of processes (think programs) that communicate with each other, to allow the main loop to be rendering only. That way, all the non-rendering tasks will be running on separate cores (threads/processes), while the main loop will only be doing rendering stuff, blazingly fast.)


— Hooray (Tue Sep 09). Re: How dangerous is Rembrandt in general?.
(powered by Instant-Cquotes)
Cquote2.png

For additional information, please see FlightGear HLA support (High Level Architecture). Also see FlightGear CIGI Support (Common Image Generator Interface).

External links