> 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 > AMEN!!
JW > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
