Hi, here's a "few" more comments/hints/warnings on Nasal and simulation performance in general.
First of all: it's not meant _against_ anybody. It's great to have a tiny scripting engine in FG. It's great to have an option for custom extensions. And we're certainly seeing very nice examples (absolutely including ThorstenIR's local weather, since he brought that up). I'm just making a point here that the Nasal engine does have performance issues, which we should be aware of and care about. When evaluating simulation performance, don't get fooled by the frame rate. What's really important to us is the "worst case frame latency". Even if the system is producing a huge average of 100 frames per second, it can still look absolutely crappy, if only a single frame took more than 20-30ms, since that's immediately visible to the human eye (note to self: add a "worst case latency" indicator). So, we're building a real-time system here, and 20-30ms is our timing constraint. Nasal needs to run a garbage collection every now and then. This means an extra delay, and may become noticeable, if it causes a frame to violate the timing constraint. _When_ and _where_ in the Nasal code the g/c triggers, is almost random, so you cannot attribute the g/c delay to the point where it happened. The effect depends on two properties: (1) how long does it take, and (2) how often does it happen. These issues are triggered by different properties of the code. If we can keep the delay below the limit, everything is perfect. If we cannot, than we should at least reduce its frequency. One stutter per minute may be acceptable. Once every second looks absolutely intolerable (though you may still get a funky 100fps indication!). 1. The length of the delay depends on the number of references the garbage collector needs to traverse: variables (data), but also functions, which are just like variables in Nasal, e.g. var myVariable = 42; var myFunction = func()... It doesn't depend on the size of a particular function or basic variable though. The garbage collector needs to look and follow every single reference to find out what's still in use. The delay is proportional to the number of elements which were loaded/initialized/created in Nasal. It hardly depends on the length/complexity/frequency of Nasal computation though, since the average number of references usually won't change too much. I have instrumented the Nasal g/c to show the number of references caused by generic Nasal scripts and by different aircraft (subtracting the references caused by generic scripts) with current GIT: 39128 all generic stuff (i.e. fgdata/Nasal...) 3475 UFO 4788 c172p 6007 SenecaII 8283 B777-200ER 19270 F14 86122 Concorde So, for most aircraft, the a/c specific Nasal is negligible. Time consumed by garbage collection almost depends on generic stuff alone (40K of references traversed in each run). Only some complex aircraft significantly influence the g/c performance themselves, e.g. the Concorde. It's ok if advanced models require advanced CPUs. But it's not so nice with generic stuff, since it affects everyone and every aircraft. Currently, we load all fgdata/Nasal/*.nas at startup. Whether the code is ever used or not, or a particular feature is disabled, doesn't matter much. It's loaded and initialized, increases the number of references, thus delays the g/c. For the test above, I had _disabled_ multiplayer/wildfire/target tracking/local weather/redout. The numbers hardly change when enabling features though. Since the local weather topic was mentioned: yes, it's large, but only responsible for about 11K of references, so about 1/4 of current generic Nasal stuff (when disabled). 2) The g/c frequency mainly depends on how much stuff is done in Nasal, including the number of timers and the timer frequencies. So, in contrast to (1), this very much depends on enabled features, and strongly on specific aircraft (see Robert's email on frequency). I also added instrumentation here to see how our generic stuff is doing. There's several timers which run at full frame rate, even when the related feature is disabled: fgdata/Nasal/mp_broadcast.nas:146 fgdata/Nasal/redout.nas:93 fgdata/Nasal/wildfire.nas:506 fgdata/Nasal/track_target.nas:194 Even when they're almost doing nothing, it'd still help if they were stopped or at least slowed down, when the related feature was disabled. They affect garbage collection since a lot of (useless) contexts are created and need to be cleared at some point - hence triggering the g/c more often than necessary. Typically many of our Nasal timer handlers look like this: myTimer = func() { if (getprop("/foo/feature/enabled")) { ... } settimer(myTimer, 0.0); // run again in next update loop } This would already improve things (20-100 times fewer contexts being created/removed): myTimer = func() { if (getprop("/foo/feature/enabled")) { ... settimer(myTimer, 0.0); // enabled, fast update (once per frame) } else { settimer(myTimer, 1.0); // disabled, slow update (once per second) } } You could also add a listener to "foo/feature/enabled" to start related timers only when really necessary. See this fix (for track_target.nas): https://www.gitorious.org/fg/fgdata/commit/d8249ef54a96c7c71bfbf187df349bdcbfabe0cb Apparently "local weather" is another good example here: I saw none of it running, unless I enabled the feature (well done!). Apart from timers, authors will know best how to limit/reduce the load of their scripts. And of course, similar improvements would help specific aircraft. Conclusion: * We want a smooth simulation, not just a high frame rate. * Nasal is great for small stuff, but it's currently not designed to hold large amounts of code or data. * We can ignore the issues (accept jitters or keep buying faster machines). * We can try to improve the Nasal engine, i.e. accelerate garbage collection, but it's probably very tricky and not going to happen (volunteers?). * We can try to avoid / lessen the issue: implement larger generic stuff without Nasal (C++, XML animation rules etc), by improving Nasal scripts itself (see above), or by loading generic Nasal scripts on demand/when enabled only (so users can choose). And since something like "don't complain, just do it" was mentioned: I'm not complaining (my new machine is doing fine for now). I've just analyzed it and mention the facts. Yes, I think it'd be good to see some generic things ported over to C++: indeed local weather, but some multiplayer stuff too. But no, I'm not going to port it - at least not local weather (feel like messing with enough modules already :) ). Over and out, :) 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