Re: [Flightgear-devel] Nasal performance
Thorsten, Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in terms of cloud count). http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz Yes, that improves it here really much! First, quite subjective impression: -Less stutters, more stable -framerate impact comparable with Default clouds Now it seems to make fun, and makes FGFS does looks great again! Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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 Tue, 2012-05-22 at 13:00 -0700, Andy Ross wrote: I was lucky enough to notice this come by. I wouldn't hold your breath. :) Hi Andy, how's life? I did already search for a new release of Nasal on your site but I believe flightgear already uses the latest version. 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 Tuesday 22 May 2012 13:04:24 Andy Ross wrote: On 05/20/2012 11:37 AM, Stefan Seifert wrote: 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 Runtime, yes, but not latency bounds. You still have to touch the whole heap eventually. But you're right: allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster. Maybe even simpler: run the GC in a separate thread. Threaded GC usually is quite tricky but in this case it may not be that much of a problem. Is there any time during processing a new frame when no Nasal is run but something else which is time consuming? This could be the perfect point to hide the GC's latency. FG does not use multiple cores that well so there should be at least one core which is bored and might tend to the garbage instead while the main thread is busy rendering pretty graphics. A single condition var might be enough to ensure that the GC is not running at the same time as Nasal execution. In my naive imagingation, this sounds like a single evening experiment ;) 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
Re: [Flightgear-devel] Nasal performance
On 05/23/2012 12:04 AM, Erik Hofman wrote: Hi Andy, how's life? I did already search for a new release of Nasal on your site but I believe flightgear already uses the latest version. The most recent code (except for a few modules that were never imported) is in SimGear. I threw my copy up on github a while back if there is any question about variants: https://github.com/andyross/nasal Andy -- 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 Wed, 23 May 2012, Stefan Seifert wrote: Maybe even simpler: run the GC in a separate thread. Threaded GC usually is quite tricky but in this case it may not be that much of a problem. Is there any time during processing a new frame when no Nasal is run but something else which is time consuming? This could be the perfect point to hide the GC's latency. FG does not use multiple cores that well so there should be at least one core which is bored and might tend to the garbage instead while the main thread is busy rendering pretty graphics. A single condition var might be enough to ensure that the GC is not running at the same time as Nasal execution. In my naive imagingation, this sounds like a single evening experiment ;) It was, but there is still the issue that you can't execute Nasal while the GC is running (for that you'd need a concurrent GC which is most likely not so easily implemented). The implication is that if the time required for a collection exceeds the frame dealy you'll still notice it even when the GC runs in a different thread. I have updated my experimental patch from last year, which should also work on Windows now (and it has even been tested there): http://sleipner.gidenstam.org/users/anders/FlightGear/sg-gc-4.diff http://sleipner.gidenstam.org/users/anders/FlightGear/fg-gc-3.diff Again: It doesn't solve the bigger problem of the current Nasal GC needing to run uninterrupted and in mutual exclusion - but I see very few GC runs in the main loop here (the patch prints ** Nasal GC in main thread ** in the console when that happens) except a few during startup. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- 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
(Even if this works fine, please do not commit yet, I am not 100% sure
that I didn't create an instability somewhere).
Turns out I broke at least the visibility interpolation - to restore it,
uncomment line 726 in Nasal/local_weather/local_weather.nas
if (vis 0.0) {setprop(lwi~visibility-m,vis);} # a redundancy check
(there's a better way to deal with this, but for the time being that seems
to
solve the problem).
I have tested using only the test tile so far. The time spent in events is
dramatically reduced to around 70ms vice 210ms. There remains some odd
cyclical frames coming in, but the results are broadly in line with Basic
Weather. The details are here:
http://dl.dropbox.com/u/57645542/Adv-Weather-data.png
I tried some airborne tests using the test tile, and the visual results are
satisfactory, again comparable to Basic Weather. The spikes in framerate can
be measured, but are not too visually intrusive. Like you, I have been
unable to identify the source so far.
I extended the test by setting all settimer loops to 0.0. There was little
measurable change in either frame rate or stability.
I'm now going to test with more representative weather.
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
I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these lines then, although I expect that the rest is just cleanup work which will not gain that much performance any more. The biggest issue is that in this version the movement of the Cirrus clouds is broken, and under some (somewhat unusual) conditions that would show (since tiles themselves still move, there'd be a pileup of clouds in a given location in strong winds if the aircraft doesn't move much). But it seems the quadtree code to move them is simply too heavy - either a lighter scheme is needed, or some other solution. What's the prospect of adding hard-coded movement to models loaded from Nasal? AI models defined on startup can have a heading and an airspeed and these can even be changed at runtime - just models loaded from Nasal at runtime don't seem to have that feature, and so they require per frame position updates from Nasal. * 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 05/20/2012 10:17 AM, 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 was lucky enough to notice this come by. I wouldn't hold your breath. :) This was an experiment, and honestly I have no idea why I put it in the docs. The idea was to do the GC normally, check timestamps periodically, and then longtmp() out of it past some threshold, leaving the intermediate sweep stuff in place. But that's not enough, because now you need to track all mutated reference-storing objects in a separate list so they can be swept again. And you need to have some kind of heuristic for when it's OK to restart the sweep. I have a vague memory of being sure I'd cleverly solved this, but I never got it working and at this point, frankly, I suspect I was wrong. In my advancing age, I've come to believe that low-latency GC is just a pipe dream. You can have a realtime GC or you can have a production system, but you can't have both at the same time. Every managed runtime in the modern world has latency bugs in some application or another, every one of them. Andy -- 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 05/20/2012 11:37 AM, Stefan Seifert wrote: 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 Runtime, yes, but not latency bounds. You still have to touch the whole heap eventually. But you're right: allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster. Andy -- 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 I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these lines then, although I expect that the rest is just cleanup work which will not gain that much performance any more. The biggest issue is that in this version the movement of the Cirrus clouds is broken, and under some (somewhat unusual) conditions that would show (since tiles themselves still move, there'd be a pileup of clouds in a given location in strong winds if the aircraft doesn't move much). But it seems the quadtree code to move them is simply too heavy - either a lighter scheme is needed, or some other solution. What's the prospect of adding hard-coded movement to models loaded from Nasal? AI models defined on startup can have a heading and an airspeed and these can even be changed at runtime - just models loaded from Nasal at runtime don't seem to have that feature, and so they require per frame position updates from Nasal. Looks doable - but then everything does until the difficulties become apparent :-) I'm just doing a little experimentation here now on that. 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
Not that we're there yet Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in terms of cloud count). http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz I've tested this in the default shading with the ufo in window mode without expensive shaders running so that I got a high framerate. I've seen framerates of 65 fps with max frame delays of order 15 ms (which seems okay so far). Every few seconds there was a prolonged frame of 30 ms (still within my design targets, but suspicious). I've tested the hypothesis that the only loop not running per frame now causes this (the tile management loop) and switched it off - the problem persisted unchanged, so to my ability to test this feature was not caused by any Nasal code running (it might still have to do with Nasal overhead like GC or so, that I couldn't establish). Every 30-40 seconds I had a freak-frame of 150 ms duration coming in. To test what is going on here, I disabled all running Nasal code by clear/end - the problem persisted. To my ability to test, this is also not caused by running Nasal code but by something which I couldn't identify. I've subsequently tested the visual impression of flying with an aircraft rather than the ufo and took the Harrier for a spin through 6/8 cloud cover (one of the low pressure scenarios). It certainly felt smooth to me, although the framerate and frame delay readings were a bit more jittery than with the ufo. So, I'd like to know if that helps you as well and if we're on the right track here. (Even if this works fine, please do not commit yet, I am not 100% sure that I didn't create an instability somewhere). * 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 Not that we're there yet Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in terms of cloud count). http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz I've tested this in the default shading with the ufo in window mode without expensive shaders running so that I got a high framerate. I've seen framerates of 65 fps with max frame delays of order 15 ms (which seems okay so far). Every few seconds there was a prolonged frame of 30 ms (still within my design targets, but suspicious). I've tested the hypothesis that the only loop not running per frame now causes this (the tile management loop) and switched it off - the problem persisted unchanged, so to my ability to test this feature was not caused by any Nasal code running (it might still have to do with Nasal overhead like GC or so, that I couldn't establish). Every 30-40 seconds I had a freak-frame of 150 ms duration coming in. To test what is going on here, I disabled all running Nasal code by clear/end - the problem persisted. To my ability to test, this is also not caused by running Nasal code but by something which I couldn't identify. I've subsequently tested the visual impression of flying with an aircraft rather than the ufo and took the Harrier for a spin through 6/8 cloud cover (one of the low pressure scenarios). It certainly felt smooth to me, although the framerate and frame delay readings were a bit more jittery than with the ufo. So, I'd like to know if that helps you as well and if we're on the right track here. (Even if this works fine, please do not commit yet, I am not 100% sure that I didn't create an instability somewhere). Testing underway, 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
(Even if this works fine, please do not commit yet, I am not 100% sure
that I didn't create an instability somewhere).
Turns out I broke at least the visibility interpolation - to restore it,
uncomment line 726 in Nasal/local_weather/local_weather.nas
if (vis 0.0) {setprop(lwi~visibility-m,vis);} # a redundancy check
(there's a better way to deal with this, but for the time being that seems to
solve the problem).
* 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] 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
