High-Level Architecture: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(+ External link: Wikipedia article; Copyediting – Please do not copy text straight off from Wikipedia)
m (add quotes from forum to help explain HLA in layman's termss)
Line 2: Line 2:


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
  |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) ?<br/>
That's basically in line with how FlightGear is going to work once HLA materializes a little more.<br/>
<br/>
The main problem here is that most "legacy" software (like FlightGear) was originally written for a computer with a single processor (CPU). <br/>
<br/>
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 &lt;{{=}} 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.<br/>
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).
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}
{{FGCquote
  |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. <br/>
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.<br/>
<br/>
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).
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}
{{FGCquote
  |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.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}
{{FGCquote
  |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. <br/>
<br/>
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.<br/>
<br/>
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 <br/>
<br/>
Equally, the OS may decide to kill FG because it doesn't manage memory properly
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}
{{FGCquote
  |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.<br/>
<br/>
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".
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}
{{FGCquote
  |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.<br/>
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.<br/>
<br/>
(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.)
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218069#p218069
    |title=<nowiki>Re: How dangerous is Rembrandt in general?</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Sep 09</nowiki>
  }}
}}


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

Revision as of 02:01, 9 September 2014

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