On 26.03.2011 06:27, Robert wrote:
Well, yes. But changing current scripts would be a huge, huge
project. And it'd would require much more maintenance than our tiny
Nasal engine. It's a better option to improve the existing garbage
collector (i.e. use reference counting, improve its speed, or make
it happen less often). But that would also be a very complex change
in a very sensitive area of our sources.
However, the garbage
collector does a complete scan of all Nasal objects to
detect and remove unreachable elements. So, the more Nasal
data elements we have, the worse the jitter gets. Large
Nasal data structures will eventually break every CPU. And
since it's done in the context of normal Nasal calls, and
not in a separate background thread, it directly affects the
duration of our main update loop - hence frame rate. Not so
Hmm. Other script languages rely on reference counting for
garbage collection, which means much more stable
performance. Python does that for example. But, well... GSoC
Python support would be a great feature I think.
Mainly dreaming. Such things may look simple at first. Easy to
convert a simple "hello world". But it's very complex when
supporting all the features of an interpreted script language. And
the funny thing is: you'd still need to worry about automatic
garbage collection and count references (though that'd be a lesser
issue compared to many others then). So, time wake up...
What I am thinking about is a possibility to convert Nasal
scripts to C or C++ and compile them as shared objects (.so
.dll). Then we could load them dynamically at fgfs runtime. So
in the end we get raw C/C++ performance to our modules.
Is this possible or am I dreaming of something impossible here?
For the time being, we'll have to live with this. We should just be
aware, that introducing too complex data structures and too
heavy/complex computations in Nasal isn't a good idea. Even when
their average execution time looks ok, they will eventually trigger
noticeable frame rate jitters. The larger the data structures get,
the longer the jitter. The more heavy the computation gets, the more
often the garbage collector has to run, the more often the jitter
So, it's still good to implement heavy stuff and common instruments
in our FG core (C++), and use Nasal mainly for aircraft-specific
animations etc. Though that may not be the direction our project is
heading to right now...