[Flightgear-devel] Nasal performance
88 declared but unused variables
47 declarations of the same or similar variables
427 instances of else if instead of elsif
100 instances of I = I + 1 instead of i+=1
Numerous examples of variables declared inside for loops, and some of those
are inside other for loops
Variables declared inside condition statements.
So, just to get this out of the way, some benchmark tests. As you have probably
discovered by now, elseif isn't valid syntax and leads to a parse error, so my
427 instances of using it are trivial to justify :-)
Execution time of various code snippets:
===
for (var i = 0; i 1000; i=i+1)
takes 2.3 seconds or 0.00023 ms per iteration. The loop structure itself, even
if you run it up to 1000 iterations inside a frame, delays the frame only by
0.23 ms.
===
for (var i = 0; i 1000; i=i+1)
{
var testvar = 1.0;
}
takes 3.0 sec, i.e. the extra time to assign a variable inside the loop is
0.0003 ms.
===
var testvar = 1.0;
for (var i = 0; i 1; i=i+1)
{
testvar = 1.0;
}
takes 3.1 sec, i.e. declaring a variable outside the loop isn't actually any
faster, it boils down to practically the same time.
===
for (var i = 0; i 1000; i=i+1)
{
var testvar = getprop(position/latitude-deg);
}
shows that property tree interaction is an expensive operation - this takes 11
sec, i.e. the extra time to pull something from the tree is 0.00087 ms per
operation. However, even having 1000 of these per frame delays the frame just
by 0.87 ms.
===
for (var i = 0; i 1000; i=i+1)
{
var testvar = math.sin(i * 0.2);
}
executes in 16 sec, showing that trigonometry is about the same order of
expense as interacting with the property tree, i.e. having 1000 trigonometric
operations per frame delays you by 1.37 ms.
===
var info = {};
for (var i = 0; i 1000; i=i+1)
{
info = geodinfo(lat, lon);
}
Now for comparison where the real stuff is happening - this takes a whopping
350 sec to execute, i.e. executing even just 100 geodinfo() calls per frame
would delay you already by 3.4 ms. Even worse, the execution speed of
geodinfo() depends on terrain detail, the case study is TNCM where most of the
terrain is ocean, in custom scenery geodinfo can easily take much longer (for
Grenoble LFLG I get 1100 sec), i.e. a single call in custom scenery is already
about 0.1 ms of frame delay.
Oh well, and it used to be even 50 times slower than what we have now ;-)
===
This might give you some idea why optimizing the code makes only sense in some
areas - whatever you do with the Nasal-internal stuff, it's never going to come
even close to what you gain by avoiding even a single geodinfo() call. Advanced
Weather doesn't burn any significant performance inside Nasal - it burns the
performance by calling hard-coded C++ functionality from Nasal.
Cheers,
* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On Sun, 2012-05-20 at 10:43 +, Renk Thorsten wrote: Advanced Weather doesn't burn any significant performance inside Nasal - it burns the performance by calling hard-coded C++ functionality from Nasal. I hope you're not suggesting that C++ is always slower than Nasal? :-) Erik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Erik Hofman e...@ehofman.com writes:
On Sun, 2012-05-20 at 10:43 +, Renk Thorsten wrote:
Advanced Weather doesn't burn any significant performance inside
Nasal - it burns the performance by calling hard-coded C++
functionality from Nasal.
I hope you're not suggesting that C++ is always slower than Nasal? :-)
Of course it is. Think about it! Only slow functions are written in
C++! If the function was fast enough in the first place, it wouldn't
have been written in C++, it would be left in nasal. QED, C++ is the
slowest part of the system.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
So, just to get this out of the way, some benchmark tests. As you have probably discovered by now, elseif isn't valid syntax and leads to a parse error, so my 427 instances of using it are trivial to justify :-) just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Cheers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Thanks. That would explain it ;-) I hope you're not suggesting that C++ is always slower than Nasal? :-) Pascal summarized it nicely - we already have ported the important stuff to C++, so what remains in Nasal is a small fraction of the total performance cost and we gain little as such by porting that as well. I'm sure the loop computes even faster in C++, but I don't have the means to measure that. It'd be intersting though to see how much the difference actually is. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Thanks. That would explain it ;-) I hope you're not suggesting that C++ is always slower than Nasal? :-) Pascal summarized it nicely - we already have ported the important stuff to C++, so what remains in Nasal is a small fraction of the total performance cost and we gain little as such by porting that as well. I'm sure the loop computes even faster in C++, but I don't have the means to measure that. It'd be intersting though to see how much the difference actually is. It was just a couple of mouse clicks to remove the unused vars and change to elsif. The best than can be said is that if I look really closely I can convince myself that there is less time spent in Events - from about 210 ms down to 195. The worst that can be said is that it looks a bit prettier. Improved frame rate? Possibly. It's just tinkering on the margins, as you said. I didn't do more than that - since it was more than a couple of mouse clicks, and I expect that we will gain much more by removing redundant code so that GC has less to do. Just to remind ourselves, Andy Ross (the author of Nasal) says: Performance is not a design goal. Nasal isn't especially slow. Early benchmarks of the garbage collector showed it as faster than perl's reference counter, and its number crunching performance is on par with python. But in all cases, simplicity, transparency and a sane feature set are preferred over speed. It is a scripting language that is an abstraction layer over C, so we might expect it not to be as quick as code written in directly in C++. And as we know, we're running into GC issues. Andy also says of GC: The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a return early capability for latency-critical applications. The collector can be instructed to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the small and simple criteria and are not likely to be included. I don't think it was a design aim to handle time-critical stuff like Advanced Weather: that it does is a bonus. Were the future enhancements ever implemented? I don't recall. Porting to C++ might be a little faster, but it might also be the only way to avoid GC issues. Not that we're there yet: here with all settimers() set to 0.0, I can get acceptable framerate and stability. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On 20 May 2012, at 17:59, Vivian Meazza vivian.mea...@lineone.net wrote: The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a return early capability for latency-critical applications. The collector can be instructed to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the small and simple criteria and are not likely to be This is interesting - as far as I know, the current GC does not include a maximum delay and restart facility. If it did, that would entirely satisfy the current issues. At least by my understanding. Equally, I've looked at the current GC code and didn't notice any code to support this feature. Does anyone else have any further information about this? Since it would be far simpler and more robust than any other solution thus suggested. Regards, James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pitch and Roll interpretation in STG files
Hi all, After an IRC session with Anders Gidenstam (a big thanks to him) I'm able to give you a new git diff. This new git diff fix the possible bugs about *nix/Windows end of line (\n or \r\n) and give a full compatibility between old and new STG parser. The git diff is available here : http://pastebin.com/Z2qDPJ3P The next step is to give the possibility to UFO export pitch and roll value in console when key d is pressed. Who is able to do it ? Just an example of what does the patch? : http://clemaez.fr/flightgear/Screenshot/fgfs-screen-018.png Left fence is without the patch, right fence is with the patch. Another example here with straw bale : http://clemaez.fr/flightgear/Screenshot/fgfs-screen-020.png Cheers, Clément -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On Sun, 2012-05-20 at 13:58 +, Renk Thorsten wrote: just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Thanks. That would explain it ;-) I hope you're not suggesting that C++ is always slower than Nasal? :-) Pascal summarized it nicely - we already have ported the important stuff to C++, so what remains in Nasal is a small fraction of the total performance cost and we gain little as such by porting that as well. I'm sure the loop computes even faster in C++, but I don't have the means to measure that. It'd be intersting though to see how much the difference actually is. These types of measurements are always great, you can discuss endlessly and all prove to be wrong in the end. Erik PS. calculating geod is always heavy and a wise man once said; the fastest code is the code that doesn't run. This is true both for nasal and for C++ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On Sun, 2012-05-20 at 19:17 +0200, James Turner wrote: This is interesting - as far as I know, the current GC does not include a maximum delay and restart facility. If it did, that would entirely satisfy the current issues. At least by my understanding. Equally, I've looked at the current GC code and didn't notice any code to support this feature. Does anyone else have any further information about this? Since it would be far simpler and more robust than any other solution thus suggested. I did a bit of thinking about this while enjoying a sunny sunday over here today. And I start to believe that adding timestamp to the data blocks and by making sure new blocks are inserted at the beginning of the linked list is would be easy to do something like this for the garbage collector: * process the linked list every second up to the point that timestamps get older than 8 seconds. * process blocks that are older than 8 second and less than 1 minute every minute. * treat blocks that are older than 1 minute as semi-permanent and only process them incrementally with (say) 16 blocks at a time. It might spread the load a little that way. Erik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On Sunday 20 May 2012 16:59:40 Vivian Meazza wrote: Andy also says of GC: Fancy items like generational collectors fail the small and simple criteria and are not likely to be included. Generational garbage collection is not that difficult. When you have a working mark sweep GC, extending it to be generational is rather straight forward and can greatly reduce GC runtime. Most of all you wouldn't have to care about long lived objects like code itself anymore, since it's only for the first couple of runs where it gets marked. Adding generations to the GC is probably one of the simplest ways to improve FGs performance. Stefan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
