On 26.03.2011 06:27, Robert wrote:
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 nice.
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 anyone? ;-)
Python support would be a great feature I think.
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.
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?
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...
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 happens...
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...
cheers,
Thorsten
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
