20,741
edits
| Line 36: | Line 36: | ||
Additionally, using an existing GC allows you to take advantage of the expertise and knowledge of the GC developers, who have likely spent a great deal of time optimizing and improving the GC. This can save you a significant amount of time and effort, and can help you avoid common pitfalls and mistakes that are often made when developing a new GC. | Additionally, using an existing GC allows you to take advantage of the expertise and knowledge of the GC developers, who have likely spent a great deal of time optimizing and improving the GC. This can save you a significant amount of time and effort, and can help you avoid common pitfalls and mistakes that are often made when developing a new GC. | ||
=== Moving Scripts into Threads === | |||
Over the years, FlightGear has become infamous for its comparatively poor utilization of multi-core computers, where there's often only one or two CPUs being utilized, with many others being left idle. This is regularly brought up by end-users who have experience using other, often more complex, software on the same setup. | |||
Thus, another goal of this article is to better understand how the existing Nasal integration inside FlightGear could be adapted or extended/improved for future scripts to make better use of multi-threading, without having to run inside the FlightGear main loop, potentially blocking frame rate/latency (spacing). The idea would be to come up with a new optional runtime mode for certain scripts to be executed outside the main loop. | |||
Therefore, porting the Nasal scripting interpreter from C to C++ -while being really straightforward to do- would allow us to get rid of the Globals struct and instead use proper OOP (i.e. one Nasal instance per object), so that it would also become trivial to use several independent instances of a Nasal interpreter at runtime, so that certain, well-behaved, scripts could indeed be running inside their own SGThread, separate from the main loop and separate from other unrelated Nasal scripts. While this would mean, that FlightGear would use more cores, it would mean that the GC overhead caused by such scripts would be moved out of the main loop. | |||
== Status == | == Status == | ||