Re: [Flightgear-devel] Musings on optimizing Nasal code
On Thu, Sep 16, 2010 at 1:28 PM, wrote: > > You just discovered that Nasal is 10x slower than C++ > > code! This is exactly why I prefer core code to end up in C++ in the end. > > I don't think that's a valid interpretation of my results. Consider the > two cases where I achieved a significant performance gain by replacing > hard-coded structures with my own Nasal code (range animation, > distance_to() method) - you wouldn't conclude from that that Nasal is > faster either. > > I think what I have discovered is that well-designed code runs much faster > than merely working code and that there's room for improvement in some > places and it's worth looking for that room. > > Here's a case where your original Nasal code was the better algorithm: it "ought" to be better to hold the property tree nodes and index them explicitly using getChild() than to create a property tree path string for each child. However, the code that parses property tree paths has been optimized, especially to allocate as little heap storage as possible, so its speed outclasses the Nasal parser. > The algorithm being equal, I don't think there's a question that C++ is > faster (I doubt the factor 10 though - that seems to be an extreme case). > Everything else being equal, I also don't think there's a question that > Nasal code is more accessible. And I would base any decision what to > hard-code and what not on that balance. > > Well, just my 2 cents... > > * Thorsten > > There's no question that scripting languages are good; fgfs has a lot of Nasal code now. In my profiling I have never seen the nasal interpreter as a hot spot, though I haven't profiled the new weather or some of Vivian's experiments. At some point we might need to get more eyeballs looking at Nasal performance. Tim -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
> The distance_to() method is a pretty standard "great circle" calculation, > and that's exactly its purpose. Are you sure your "faster" version does > the same? Does it yield the same (numeric) results? And besides, in the > visual range direct_distance_to() should be good enough, and it's > certainly > faster. I doubt that considering Earth curvature is *that* important for > cloud distances. See http://www.flightgear.org/forums/viewtopic.php?f=30&t=9495 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
* thorsten.i.r...@jyu.fi -- 9/16/2010 1:28 PM: > I don't think that's a valid interpretation of my results. Consider the > two cases where I achieved a significant performance gain by replacing > hard-coded structures with my own Nasal code (range animation, > distance_to() method) The distance_to() method is a pretty standard "great circle" calculation, and that's exactly its purpose. Are you sure your "faster" version does the same? Does it yield the same (numeric) results? And besides, in the visual range direct_distance_to() should be good enough, and it's certainly faster. I doubt that considering Earth curvature is *that* important for cloud distances. m. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
> You just discovered that Nasal is 10x slower than C++ > code! This is exactly why I prefer core code to end up in C++ in the end. I don't think that's a valid interpretation of my results. Consider the two cases where I achieved a significant performance gain by replacing hard-coded structures with my own Nasal code (range animation, distance_to() method) - you wouldn't conclude from that that Nasal is faster either. I think what I have discovered is that well-designed code runs much faster than merely working code and that there's room for improvement in some places and it's worth looking for that room. The algorithm being equal, I don't think there's a question that C++ is faster (I doubt the factor 10 though - that seems to be an extreme case). Everything else being equal, I also don't think there's a question that Nasal code is more accessible. And I would base any decision what to hard-code and what not on that balance. Well, just my 2 cents... * Thorsten -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
On Thu, 2010-09-16 at 08:59 +0200, Anders Gidenstam wrote: > I think a bigger issue might be that both getChild() and getNode() > create and return a hash object that is only used once here before > becoming garbage. Since this was loop with many iterations a good deal of > garbage was created so possibly a significant amount of the time was spent > in the garbage collector. OTOH the string handling also ought to generate > garbage but the short strings are probably smaller than the hash objects. No doubt that Nasal can be optimized in certain parts put parsing "/path/to/some/property[5]/in/the/tree" to getprop/setprop will result in one call to a C++ function that walks the property tree and returns the result to Nasal. Erik -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
On Wed, 15 Sep 2010, Erik Hofman wrote: > After thinking about it I think that in the second case the property > tree is being walked trough by the C++ code while in the first case it's > done in Nasal. You just discovered that Nasal is 10x slower than C++ code! > This is exactly why I prefer core code to end up in C++ in the end. > > That said, Nasal performance tests are always useful. Hi, I think a bigger issue might be that both getChild() and getNode() create and return a hash object that is only used once here before becoming garbage. Since this was loop with many iterations a good deal of garbage was created so possibly a significant amount of the time was spent in the garbage collector. OTOH the string handling also ought to generate garbage but the short strings are probably smaller than the hash objects. My 1 minute of thought to the morning coffee.. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
thorsten.i.r...@jyu.fi wrote:
> I've just spent a session optimizing performance of the weather dynamics
> routines, and I have largely done so by analyzing the performance of
> elementary Nasal function calls and making use of my findings (and also by
> dispensing with the pretense of elegant coding).
>
> I was rather gratified to see the framerate improve significantly - a test
> configuration which used to render at ~20 fps is now blasting away at ~60
> fps. Given that I achieve only ~75 fps for the same cloud configuration if
> I don't move any clouds, that's probably quite good already. In practical
> terms, I usually get now above a comfortable 30 fps with the F-14b in a
> drifting noon population of Cumulus clouds.
>
> This almost miraculous increase was to a good part achieved by
> consistently banning any use of the props or geo classes from
> performance-critical code. To give an example - it turns out that while
>
> node = props.globals.getNode("test",1);
> for (var i = 0; i < n; i = i +
> 1){node.getChild("array",i,1).getNode("test",1).setValue(value);}
>
> is an elegant structure to initialize or write an array of properties in
> the tree, the ugly variant
>
> for (var i = 0; i < n; i = i + 1){setprop("test/array["~i~"]/test", value);}
> is ten (!) times faster. Basically, replacing an instance of a props
> method with getprop() or setprop() seems to give at least a factor 2 in
> speed, often more.
>
After thinking about it I think that in the second case the property
tree is being walked trough by the C++ code while in the first case it's
done in Nasal. You just discovered that Nasal is 10x slower than C++ code!
This is exactly why I prefer core code to end up in C++ in the end.
That said, Nasal performance tests are always useful.
Erik
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Musings on optimizing Nasal code
I've just spent a session optimizing performance of the weather dynamics
routines, and I have largely done so by analyzing the performance of
elementary Nasal function calls and making use of my findings (and also by
dispensing with the pretense of elegant coding).
I was rather gratified to see the framerate improve significantly - a test
configuration which used to render at ~20 fps is now blasting away at ~60
fps. Given that I achieve only ~75 fps for the same cloud configuration if
I don't move any clouds, that's probably quite good already. In practical
terms, I usually get now above a comfortable 30 fps with the F-14b in a
drifting noon population of Cumulus clouds.
This almost miraculous increase was to a good part achieved by
consistently banning any use of the props or geo classes from
performance-critical code. To give an example - it turns out that while
node = props.globals.getNode("test",1);
for (var i = 0; i < n; i = i +
1){node.getChild("array",i,1).getNode("test",1).setValue(value);}
is an elegant structure to initialize or write an array of properties in
the tree, the ugly variant
for (var i = 0; i < n; i = i + 1){setprop("test/array["~i~"]/test", value);}
is ten (!) times faster. Basically, replacing an instance of a props
method with getprop() or setprop() seems to give at least a factor 2 in
speed, often more.
Similar with geo distance calculation methods.
Maybe you already know all of this. In case you don't and you're running
Nasal on a per frame basis anywhere, you may want to have a look into the
details of the tests.
http://www.flightgear.org/forums/viewtopic.php?f=30&t=9493
http://www.flightgear.org/forums/viewtopic.php?f=30&t=9495
Cheers,
* Thorsten
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
