20,741
edits
Nasal GC Musings: Difference between revisions
Jump to navigation
Jump to search
m
→Moving Scripts into Threads
| Line 44: | Line 44: | ||
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. | 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. | ||
One potential issue with using embedded scripting in FlightGear is that the simulator uses a single-threaded main loop. This means that (by and large) all of the simulator's functions are executed one after the other, without any parallelism. This can be a problem when using garbage collection (GC), especially a purely sequential mark/sweep algorithm that cannot be parallelized. | |||
In a single-threaded environment, garbage collection can cause delays in the execution of the main loop. This can result in frame rate and spacing issues, which can affect the overall performance of the simulator. In other words, garbage collection can cause the simulator to become unresponsive or slow down, leading to a poor user experience. | |||
In modern web browsers, JavaScript is used to add interactivity and dynamic functionality to web pages. Like FlightGear, web browsers used to use a single-threaded main loop to execute JavaScript code in a blocking fashion. This meant that garbage collection in JavaScript could cause similar issues, such as delays and unresponsiveness. | |||
Modern web browsers these days support so called web extensions. Web extensions are a way for developers to add custom functionality to the browser, and they are executed in background threads. FlightGear as a project could learn how to improve the integration of its scripting engine by looking at web extensions and background scripts | |||
== Status == | == Status == | ||