On Sat, Mar 26, 2011 at 6:27 AM, Robert <dogg...@googlemail.com> wrote: >> Indeed the jitter is caused by Nasal's "garbageCollect" method. Simple >> test: add a printf (apply attached "patch" to simgear) and you should see >> the "stutter" is synchronized with it. > > True! The text is printfed with every jitter. > >> >> Well, there is a workaround! Use a faster CPU :). I see a jitter of about >> 7ms with most aircraft. > > Wow 7 ms is very good. I hardly notice a 10 ms jitter, at full 75 fps. > But something around 20 ms gets very prominent. > >> >> 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? ;-) Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated.
I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. > > Python support would be a great feature I think. It is used in many products > (e.g. in Blender) and that is a plus. However it's not guaranteed that it is > free of such problems until you port all current Nasal scripts to Python and > test it. > 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? > What do you think? Why not write the modules in C++ to begin with? Tim ------------------------------------------------------------------------------ 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
