753
edits
Fr/High-Level Architecture: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
(Traduction partielle) |
mNo edit summary |
||
| Line 19: | Line 19: | ||
{{Multicore}} | {{Multicore}} | ||
'''High-Level Architecture''' ('''HLA''') est une architecture à usage général destinée aux systèmes de simulation informatique distribués. | '''High-Level Architecture''' ('''HLA''') est une architecture logicielle à usage général destinée aux systèmes de simulation informatique distribués. | ||
Au lieu d'avoir toute la simulation dans un seul exécutable (architecture monolithique), la simulation est répartie en différents modules fédérés ([[Federate]]), qui interagissent les uns avec les autres par une infrastructure d'exécution RTI (Run-Time Infrastructure, un bus de messages qui gère la sérialisation des messages, des événements et des objets). Les modules fédérés sont généralement exécutés dans leurs propres [https://fr.wikipedia.org/wiki/Thread_(informatique) threads]/processus et chaque processus fédéré a accès à l'intégralité de l'espace d'adressage du processus virtuel fourni par le système d'exploitation au lieu d'avoir à le partager avec d'autres sous-systèmes (c'est-à-dire que les plates-formes 32 bits peuvent utiliser la RAM virtuelle de | Au lieu d'avoir toute la simulation dans un seul exécutable (architecture monolithique), la simulation est répartie en différents modules fédérés ([[Federate]]), qui interagissent les uns avec les autres par une infrastructure d'exécution RTI (Run-Time Infrastructure, un bus de messages qui gère la sérialisation des messages, des événements et des objets). Les modules fédérés sont généralement exécutés dans leurs propres [https://fr.wikipedia.org/wiki/Thread_(informatique) threads]/processus et chaque processus fédéré a accès à l'intégralité de l'espace d'adressage du processus virtuel fourni par le système d'exploitation, au lieu d'avoir à le partager avec d'autres sous-systèmes (c'est-à-dire que les plates-formes 32/64 bits peuvent utiliser la RAM virtuelle de manière optimale). | ||
Il y a trois grands avantages à cela par rapport à une simulation monolithique (par exemple FlightGear V3.6) : | |||
<s>Rather than have the entire simulation within a single executable, the simulation is split into different [[Federate|Federates]], which interact with each other by a ''Run-Time Infrastructure'' (''RTI'', a message bus that handles serialization of messages, events and objects), with federates typically running in their own threads/processes and each federate process having access to the full virtual process address space provided by the OS instead of having to share it with other subsystems (i.e. 32 bit platforms may make better use of virtual RAM that way).</s> | <s>Rather than have the entire simulation within a single executable, the simulation is split into different [[Federate|Federates]], which interact with each other by a ''Run-Time Infrastructure'' (''RTI'', a message bus that handles serialization of messages, events and objects), with federates typically running in their own threads/processes and each federate process having access to the full virtual process address space provided by the OS instead of having to share it with other subsystems (i.e. 32 bit platforms may make better use of virtual RAM that way).</s> | ||
There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6): | <s>There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6):</s> | ||
# It provides a robust environment to make the simulator multi-threaded, taking advantage of computers with multiple cores, or indeed running different parts of the simulation on different computers (including even different platforms and operating systems). | # It provides a robust environment to make the simulator multi-threaded, taking advantage of computers with multiple cores, or indeed running different parts of the simulation on different computers (including even different platforms and operating systems). | ||
# It allows us to split out parts of the simulator such as [[AI]] (by [[Decoupling the AI Traffic System]]), the [[FDM]], [[Nasal]] scripting <ref>http://forum.flightgear.org/viewtopic.php?p=265721#p265721</ref> and [[Supporting multiple renderers|Renderer]] from each other and less time-critical sub-systems such as [[Advanced weather|weather]] so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced [[How the Nasal GC works|Nasal GC]] impact on frame rate). | # It allows us to split out parts of the simulator such as [[AI]] (by [[Decoupling the AI Traffic System]]), the [[FDM]], [[Nasal]] scripting <ref>http://forum.flightgear.org/viewtopic.php?p=265721#p265721</ref> and [[Supporting multiple renderers|Renderer]] from each other and less time-critical sub-systems such as [[Advanced weather|weather]] so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced [[How the Nasal GC works|Nasal GC]] impact on frame rate). | ||