rogerx wrote in Sun Oct 25, 2015 9:38 pm:Ah. We might be getting somewhere here blaming Nasal code.
We could always consult with Intel (and other CPU engineers) to create an optimized register specifically for only executing nasal code. (ie. Something like SSE/MMX ...)
Nasal is implemented as a stack machine - what you suggest has basically been tried (and done) when Lua was ported to a pseudo-register VM. And there are some pretty good technical articles on the whole effort.
(Google v8/JavaScript is another assembly-language based VM)
However, Nasal's performance issues are not primarily due to it being a stack machine based VM, but due to the way its garbage collector is implemented, which is responsible for managing memory - without people having to worry about "leaks".
To learn more, see:
http://wiki.flightgear.org/How_the_Nasal_GC_worksIt is definitely possible to extend/improve the Nasal GC engine, and some of us have not just toyed with the idea, but even came up with patches for new experimental features - however, none of those were committed by any core developers, despite having been posted on the devel list.
Admittedly, implementing a completely new GC scheme is relatively involved, but it would be relatively straightforward to turn the existing GC scheme into a generational one - equally, there are existing GC libraries that implement incremental, generational and concurrent GCs for different purposes.
These are open source libs, compatible with the GPL - so could be used in FG/SG (LGPL).
Java is a language that supports a plethora of GC modes/schemes.
In general, the lowest-hanging fruit is improving the GC scheme to provide an optional GC mode next to the existing one, possibly by coming up with an abstract interface to integrate other GCs for testing purposes.
However, there are really only 3-4 people sufficiently familiar with the Nasal engine, most of them not even involved in core development, and most core developers are very much hesitant to touch this part of the engine for a number of reasons (Nasal not being actively maintained).
Given the existing backlog of patches and merge requests, most potential contributors who may work on the GC are apparently not very eager to spend our time on yet another effort that may end up being disregarded (myself included).
The other thing you mentioned (differently prioritized simulation entities) is already implemented at the SGSubsystem level.