Re: [Flightgear-devel] Performance and 3d cloud switch
On Mon, 09 Sep 2013 13:42:06 +0200, Erik wrote in message 522db40e.5050...@ehofman.com: On 09/09/2013 12:59 PM, Renk Thorsten wrote: A report of performance dramatically improving for advanced weather when 3d clouds are switched off in the rendering menu (you still get to see 3d clouds) http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983 I've played around with this, and I can't reproduce any significant framerate difference. It is true that the cloud effect file doesn't condition on the 3d cloud switch at all, so Advanced Weather generates 3d clouds no matter what you select here (it can't do 2d clouds at all) - which may be a little confusing, but I have no good idea how to handle this gracefully. Maybe the switch should go away from rendering to the Basic Weather GUI? But that's a side issue. I have no idea where any performance increase might be coming from though - as far as I know, the shaders are completely unaware of this. Can anyone reproduce the finding? Stuart, any idea where this could come from? I was testing anyhow so I did a quick test. I don't see any improvement either. What (I think) can happen is that older (fgrun) config files could cause bad behaviour, especially when properties change function between FlightGear versions (for instance the effects level slider). ..another test case suggestion: if you have a radeon card, pop that in and see how it looks with that, if you don't have a radeon card, try swap out nvidea for nouveau in your /etc/X11/xorg.conf and install your distro's nouveau and libdrm-nouveau2 etc drivers alongside your nvidea drivers and chk framerates etc there: arnt@celsius:~$ dpkg -l |grep nouveau |fmt -tu ii libdrm-nouveau2:amd64 2.4.46-2 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:1.0.9-2 amd64 X.Org X server -- Nouveau display driver arnt@celsius:~$ -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and 3d cloud switch
..another test case suggestion: if you have a radeon card, pop that in and see how it looks with that, if you don't have a radeon card, try swap out nvidea for nouveau in your /etc/X11/xorg.conf and install your distro's nouveau and libdrm-nouveau2 etc drivers alongside your nvidea drivers and chk framerates etc there: arnt@celsius:~$ dpkg -l |grep nouveau |fmt -tu ii libdrm-nouveau2:amd64 2.4.46-2 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:1.0.9-2 amd64 X.Org X server -- Nouveau display driver Point being? It's well known that the noveau driver doesn't reach the performance of the proprietary driver (and I have a laptop - pretty hard to change the cards...). In any case, that doesn't have anything to do with the observation made by the forum user. * Thorsten -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and 3d cloud switch
On Tue, 10 Sep 2013 17:55:19 +, Renk wrote in message e495a106ff5f31448739e79d34138c192a958...@mbs2.ad.jyu.fi: ..another test case suggestion: if you have a radeon card, pop that in and see how it looks with that, if you don't have a radeon card, try swap out nvidea for nouveau in your /etc/X11/xorg.conf and install your distro's nouveau and libdrm-nouveau2 etc drivers alongside your nvidea drivers and chk framerates etc there: arnt@celsius:~$ dpkg -l |grep nouveau |fmt -tu ii libdrm-nouveau2:amd64 2.4.46-2 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:1.0.9-2 amd64 X.Org X server -- Nouveau display driver Point being? It's well known that the noveau driver doesn't reach the performance of the proprietary driver ..still? My only Nvidea experience is a coupla weeks now in August on XTX Geforge GTS 260 card on the nouveau driver, while waiting for a new PSU for my 4890. FG frame rates was 15-20ish and I was able to bog it down once I started piling up on eye candy. The big surprise was how the 4890 was decent, but not much faster. (and I have a laptop - pretty hard to change the cards...). ...and pretty easy to swap out nvidea for nouveau in your /etc/X11/xorg.conf once you have the driver installed, you may have to reboot to get kms going right, though. In any case, that doesn't have anything to do with the observation made by the forum user. ..easy now, I haven't tried the nvidea driver yet, I got an XTX Geforge GTS 260 card along with my 4890 radeon card, the 4890 was too tough on my PSU, so I tried the GTS 260 on the nouveau driver and the darn thing just worked, not much slower than the 4890 on the radeon driver, the _only_ thing I did to get it working, was swap out radeon for nouveau and reboot. Easy. ;o) ..the interesting part in this thread here, is I see precisely the same psycedelic rendering errors with the 4890 on the radeon driver, as I see with GTS 260 on the nouveau driver, hence my suggestion you nvidea guys take a nouveau look if you don't have a radeon card handy. (No bug yet, RL issues.) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and 3d cloud switch
A report of performance dramatically improving for advanced weather when 3d clouds are switched off in the rendering menu (you still get to see 3d clouds) http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983 I've played around with this, and I can't reproduce any significant framerate difference. It is true that the cloud effect file doesn't condition on the 3d cloud switch at all, so Advanced Weather generates 3d clouds no matter what you select here (it can't do 2d clouds at all) - which may be a little confusing, but I have no good idea how to handle this gracefully. Maybe the switch should go away from rendering to the Basic Weather GUI? But that's a side issue. I have no idea where any performance increase might be coming from though - as far as I know, the shaders are completely unaware of this. Can anyone reproduce the finding? Stuart, any idea where this could come from? * Thorsten -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and 3d cloud switch
On 09/09/2013 12:59 PM, Renk Thorsten wrote: A report of performance dramatically improving for advanced weather when 3d clouds are switched off in the rendering menu (you still get to see 3d clouds) http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983 I've played around with this, and I can't reproduce any significant framerate difference. It is true that the cloud effect file doesn't condition on the 3d cloud switch at all, so Advanced Weather generates 3d clouds no matter what you select here (it can't do 2d clouds at all) - which may be a little confusing, but I have no good idea how to handle this gracefully. Maybe the switch should go away from rendering to the Basic Weather GUI? But that's a side issue. I have no idea where any performance increase might be coming from though - as far as I know, the shaders are completely unaware of this. Can anyone reproduce the finding? Stuart, any idea where this could come from? I was testing anyhow so I did a quick test. I don't see any improvement either. What (I think) can happen is that older (fgrun) config files could cause bad behaviour, especially when properties change function between FlightGear versions (for instance the effects level slider). Erik -- http://www.adalin.com - Hardware accelerated 4D AeonWave and OpenAL for Windows and Linux - AeonWave Audio Effects software for DJ, Instrumentalist and Vocalist -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance
Well, we did have alpha-test comparisongreater/comparison reference type=float0.01/reference /alpha-test everywhere in the cloud effect files. So it's not clear to me how transparent fragments should even make it to the shader (?). Maybe I'm still confused about something... * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance
Hi everybody, I just had the chance to compile a recent git-pull on my old and battered linux-notebook workhorse and with great delight, I noticed that I can run FlightGear again with 26fps at KSFO. I had to strip down most eye candy shaders for the GeForce Go 7400 but 3D clouds render fine without a noticable drop in framerate, even if a cloud spawns the entire screen. That was much worse a few month ago when FlightGear barely ran on that old hardware. Whoever was involved in that magic - well done! Thanks for still supporting older and weaker hardware. Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance
Hi All, While I hesitate to claim performance improvements I've not seen myself, it may be that this was caused by this commit: 266b362238d0cef5a1c4df81bacbe941ee4c59ef which discards transparent fragments. I'd be very interested if you could revert the changes in that commit and let me know if it makes any difference. Thorsten R: I've just committed a similar change to the lightfield 3d cloud fragment shader. I don't notice any difference in rendering quality with the change, but you eye may be better than mine in this case :). On a related note, I've also just pushed some changes to the 3d cloud rendering such that sprites on the back of the cloud are not rendered if they are more than 10km away (configurable in /sim/rendering/cloud3d-detail-range). On my system this gives 20-50% frame-rate increases, particularly under overcast conditions. As always, I'm very interested to hear if this makes things better or worse for others. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance issue with sim reset vs Nasal
Hi,
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to trigger some initialization code. It's fine to do so. However,
modules need to be aware that this signal triggers on _every_ simulator
reset. So, the connected code executes every time you hit Shift-ESC, use
the Relocate-in-air or Relocate-on-ground dialogs.
We had plenty of places were init code connected to
/sim/signals/fdm-initialized installed a fresh set of listeners or
started another timer-driven update loop. This results in performance
degrading with every sim reset.
The worst case scenario looks like this:
_setlistener(/sim/signals/fdm-initialized, func {
setlistener(/sim/foo, foo);
setlistener(/sim/bar, bar);
update_loop();
}
var update_loop = func {
...
settimer(update_loop,0);
}
= Initially 'foo' and 'bar' are called once whenever their respective
listener triggers. After the 2nd sim reset, they are called twice per
change, after the 10th reset they are called 10 times for each property
change.
Similar issue with update_loop: initially there's only one timer
running. After the 10th reset, there's already 10 concurrent loops...
I've fixed the issue in several places of our generic Nasal modules (so
this affected every aircraft). I've also fixed the issue for the C172
and B777 specific Nasal code. These aircraft are fine now - no
performance drop even after many sim resets. But I guess many more
aircraft suffer the same problem.
Anyway, if you ever wondered why performance is so bad with FG2.0-2.6
(not sure about earlier versions) after resetting the sim or relocating
the aircraft multiple times, you now know why ;-).
cheers,
Thorsten
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Op 26-11-10 18:12, fiers...@zonnet.nl schreef: Hi All Op 26-11-10 17:03, thorsten.i.r...@jyu.fi schreef: Am I the only one? No, you are not the only one. I made a similar observation a short while ago and mailed that to this list. I also observed that the CPU loads seem to be different. The pattern depends on airoplane and location, obviously. At the moment I am looking at a healthy situation, with two cores each 50% busy and a frame rate between 70 and 90. Only 16% of the available memory is used. It all looks oke to me in the GIT of this morning. m -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Can you compare the OSG statistics between the two binaries? Choose cycle onscreen statistics three times. I sure can, but I have no idea what I am looking at when I do that - I basically get a table with numbers which change when I move or change view direction. I'd make screenshots available, except they don't work with multithreading on. What information from the screen do you need? What am I supposed to compare? Cheers, * Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
On Sat, Nov 27, 2010 at 2:33 PM, thorsten.i.r...@jyu.fi wrote: Can you compare the OSG statistics between the two binaries? Choose cycle onscreen statistics three times. I sure can, but I have no idea what I am looking at when I do that - I basically get a table with numbers which change when I move or change view direction. I'd make screenshots available, except they don't work with multithreading on. What information from the screen do you need? What am I supposed to compare? Cheers, * Thorsten Take a screenshot with one of the system tools. I want to know which traversal -- update, cull, draw, or gpu -- appears to be slower. Tim -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Take a screenshot with one of the system tools. I want to know which traversal -- update, cull, draw, or gpu -- appears to be slower. http://frbouvi.free.fr/flightsim/fgfs-20101108-KSFO-28R.png : from a nightly build http://frbouvi.free.fr/flightsim/fgfs-20101127-KSFO-28R.png : compiled here today Both on Windows 7 Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance change?
I've had just occasion to compare performance of a GIT binary compiled on Nov 24th with a GIT binary compiled Nov 13th in one of my standard benchmark tests (which I described a while ago), and the test confirmed an impression I had yesterday in just test-flying - I've lost almost 1/3 of available framerate. The flags are --enable-fullscreen --geometry=1920x1200 --disable-real-weather-fetch --enable-auto-coordination --timeofday=noon --airport=KINS --aircraft=ufo followed by spawning a cold sector tile and observing framerate upon loading and when fully loaded. Multitherading support is 'Automatic'. With empty sky (in otherwise default condition) I get 180 fps with the Nov 13th binary and 130 fps with the new one. With the cumulus clouds fully spawned, I get 80 fps with the Nov 13th binary and 55 fps with the recent one. Less formal, my impression from yesterday was that I get 20 fps where I used to have 30 which ties in well with the above numbers. The only difference is the binary - fgdata/ and the set of comandline options are completely identical. Am I the only one? Cheers, * Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Can you compare the OSG statistics between the two binaries? Choose cycle onscreen statistics three times. Tim On Fri, Nov 26, 2010 at 5:03 PM, thorsten.i.r...@jyu.fi wrote: I've had just occasion to compare performance of a GIT binary compiled on Nov 24th with a GIT binary compiled Nov 13th in one of my standard benchmark tests (which I described a while ago), and the test confirmed an impression I had yesterday in just test-flying - I've lost almost 1/3 of available framerate. The flags are --enable-fullscreen --geometry=1920x1200 --disable-real-weather-fetch --enable-auto-coordination --timeofday=noon --airport=KINS --aircraft=ufo followed by spawning a cold sector tile and observing framerate upon loading and when fully loaded. Multitherading support is 'Automatic'. With empty sky (in otherwise default condition) I get 180 fps with the Nov 13th binary and 130 fps with the new one. With the cumulus clouds fully spawned, I get 80 fps with the Nov 13th binary and 55 fps with the recent one. Less formal, my impression from yesterday was that I get 20 fps where I used to have 30 which ties in well with the above numbers. The only difference is the binary - fgdata/ and the set of comandline options are completely identical. Am I the only one? Cheers, * Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance change?
Hi All Op 26-11-10 17:03, thorsten.i.r...@jyu.fi schreef: Am I the only one? No, you are not the only one. I made a similar observation a short while ago and mailed that to this list. I also observed that the CPU loads seem to be different. See also my message of 20 November, with subject Multithreading pattern and frame rate and the responses I received from Tim Moore and ThorstenB. I made sure the conditions of the two tests were the same as much as possible, just like you. In my case, for the two binaries, different versions of OSG were used (i.e. the latest OSG at the time of compilation in both cases). m -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options - or maybe
However, the (so far to me unknown) C++ subrouting actually bringing clouds into the visibly rendered scenery is even way slower - I can read the message that the property writing is over after the expected 2.5 seconds, but continue to see clouds appear in the scenery for 30 seconds and more. This effect of 'asynchronously', 'delayed' loading of 3D models sounds quite familiar to me and might reflect an intended feature in order to save the framerate in these moments when a densely modelled chunk of Scenery appears in the view. I don't doubt that this is an intended feature, and I don't complain that it tries to save framerate. I just have the feeling something very inefficient is causing performance drop in the first place. Consider: Stuart's 3d clouds and mine are based on very similar technology. There is a collection of textures for cloudlets, and these are rotated in the scenery towards the viewer by vertex shaders (I adapted Stuart's shaders for my purposes, so they are almost identical and I checked that my modifications did not change the performance significantly). Yet a standard 3d cloud layer loads, taking into account the different number of cloudlets, different view ranges and different texture size, builds about 1000 times (!) faster than my clouds (once it is in the scenery, there's not so much difference any more - same technology...). I know that doing things from Nasal is slower than doing it from C++, but a factor 1000 seems a bit too much to be explained that way. So my speculation is that Stuart's way of loading clouds into the scenery 'knows' that they are just identical copies of the same texture set over and over, whereas the routine doing it for me doesn't, so it burns framerate loading the same textures over and over again. Just my speculation of course... Anyway, I would *really* appreciate if anyone could take a look at the chunk of code loading models via the /models/ property node and see if that factor 1000 cannot be changed into a 100 or even a 10. Cheers, * Thorsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options - or maybe something else
Not sure, maybe it is connected with an other issue we recently discovered. There are indeed some OSG operations which don't scale well. For example, OSG keeps a simple list of references at each shared model - so each shared model knows all nodes it is shared to. Adding a new member to the list takes almost no time - no matter on how large the list is. However, removing a shared model from a node can be very expensive - since it needs to search the entire list. The issue is negligible when a model isn't shared too often (say 5000 times). But it get's really, really ugly when a model has a lot more shares (10.000). This has recently caused another really bad performance issue. Enabling random scenery objects resulted in about 60.000 cows and about 30.000 horses being created (no kidding) to populate the FlightGear scenery. Creating these friendly animals was extremely efficient (no delay to be noticed). But when a scenery tile had to be removed, it had to disconnect a few thousand shares from the shared model - and each instance had to be looked-up in a list of about 60K elements... now guess what... this took 2-10 seconds per scenery tile. Removing several tiles could easily block the thread for a minute or two - meanwhile no new scenery tiles could be loaded... That's why we had to cull all the scenery animals for now. So, the implementation for loading shared objects is really efficient - but unloading a shared model can be really terrible - heavily depending on the number of shares. When you load new clouds - does this also involve dropping older clouds (removing some shares)? *g* There's indeed a cloud story to go along with the cow story - loading clouds is comparatively easy and done by appending objects to the existing array of objects in the scenery, but unloading involves searching the array for a particular subset, which takes much longer. I spent 5 months solving that. Over the time, I have tried a number of solutions - keeping an array of pointers to the objects indexed by tile so that I don't have to search the long array for instance. The most efficient solution which is in now has been to mark each object by tile index and keep a record of currently active tiles. Then a housekeeping loop can crawl slowly through the large array, processing a few objects each frame, compare the object index with the list of active tiles and remove if no match is found. That means that clouds may still exist 20 seconds or so after their tile has formally been deleted - but then again, who cares? Unloading objects doesn't cause a peak load anywhere, instead the performance needs are spread out constantly across all frames. But that's not what the present issue is. So, let me try to explain in detail. What I do to generate a cloud is: * assemble a cloud object in Nasal space with position, altitude, tile index, texture types... as properties (and management methods) * pass that to a routine which writes into the /models/ subdirectory of the property tree and append a pointer to the subnode I create in /models/ to the Nasal object Then for me the work from Nasal is over, some C++ subsystem picks up the info from the property tree and eventually the cloud appears in the scenery. This is, by the way the same technique by which the AI tanker is created and by which objects can be at runtime placed into the scenery using the ufo. Creating the object Nasal-internally is lightning-fast - I haven't tested the limit, but I sure can assemble 1000 clouds per frame without problem. Writing properties into the tree is somewhat slower - currently I write no more than 20 clouds per frame into the tree - so if I have 20 fps, writing the 1000 clouds takes the next 2.5 seconds. However, the (so far to me unknown) C++ subrouting actually bringing clouds into the visibly rendered scenery is even way slower - I can read the message that the property writing is over after the expected 2.5 seconds, but continue to see clouds appear in the scenery for 30 seconds and more. This depends on texture quality - at one point I was testing 2048x2048 high resolution cloud textures, and it took 4 minutes (!) for all clouds to appear - simply not feasible. And one can observe that the framerate drops notably and that the load on the second CPU is high. So, I guess my question is: I am usually not loading more than 30 distinct objects, the remaining (970 in the above example) are just copies - can this information not be used to speed up the process? I believe someone on this list must be able to identify the subroutine in question, given all I can tell about it... Cheers, * Thorsten -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read
Re: [Flightgear-devel] Performance and compiler options - or maybe
thorsten.i.r...@jyu.fi wrote: However, the (so far to me unknown) C++ subrouting actually bringing clouds into the visibly rendered scenery is even way slower - I can read the message that the property writing is over after the expected 2.5 seconds, but continue to see clouds appear in the scenery for 30 seconds and more. This effect of 'asynchronously', 'delayed' loading of 3D models sounds quite familiar to me and might reflect an intended feature in order to save the framerate in these moments when a densely modelled chunk of Scenery appears in the view. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options - or maybe
Op 15-11-10 11:19, Martin Spott schreef: This effect of 'asynchronously', 'delayed' loading of 3D models sounds quite familiar to me and might reflect an intended feature in order to save the framerate in these moments when a densely modelled chunk of Scenery appears in the view. Do 3D models get unloaded once they are out of the current view or are they only unloaded when they are not in the current tile? In other words, if the viewing angle is changed and 3D models are panned out of view, will they be unloaded and later reloaded when the viewing angle is turned back to the original? This would perhaps partly explain why I am having problems with clouds being loaded again and again in local weather. The behaviour seems to be depending on cloud density, which reminds me of a caching mechanism or similar optimisation. m -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options - or maybe something else
With regard to the speed of loading models from Nasal into the scenery I was writing about a while ago, I have made some discovery yesterday. I was testing a setup in 2.0.0 with some heavy numerics running on the second CPU, and this pushed the behaviour of the framerate into the behaviour I was observing with GIT. I did some follow-up testing and discovered that while multithreading is apparently by default on in 2.0.0, it is off in GIT. I subsequently observed that when I run GIT with multithreading on in GIT, the load on the second CPU is usually modest (5-10%, but when I load the initial configuration of clouds into the scenery, it increases to 80-90%. In addition, the experience of flying with heavy cloud configurations was much smoother in GIT and the multithreading seems to take care of a good part of the difference I have seen between 2.0.0 and GIT (I don't know if all - that requires some systematic testing). So this ends up to a sugestive picture - local weather actually benefits a lot from a second CPU on board, and although it can be flown with just a single CPU, it runs much smoother with a second one (which raises the question - does Heiko who reported the framerate drop on loading models for the first time usually fly with a single CPU machine?). I still have no real understanding why this is so, or why loading a large number of *identical* models into the scenery should take a long time (I would think that one can make use of the fact that there are really multiple copies of the same model around to speed things up, and while I was told that OSG does that automatically, this isn't what I observe) - if anyone can aid my understanding, please do so, it would be rather important. Cheers, * Thorsten To follow up on my previous message: Not so with my GIT binary: Loading of the initial cloud configuration brings me down to 4 fps, and every time (!) a cloud is loaded from the buffer my framerate drops from 34+ to something like 20+ for a moment - which makes the whole experience rather jerky. I have now made a series of tests to quantify the effect. The test situation is --disable-fullscreen --geometry=1200x900 --aircraft=ufo --airport=KINS --timeofday=noon --disable-real-weather-fetch 2.0.0 prebuilt: empty sky: 190 fps with 3d clouds: 128 fps with static cold sector tile: 90 fps when loaded, 34 while loading with dynamical cold sector tile: 45 fps when loaded, 30 while loading (note that this is *not* a fair comparison between standard 3d clouds and local weather clouds as the visibility and cloud view distance is rather different - not the point of the exercise) GIT built against my self-compiled OSG 2.9.10: empty sky: 234 fps with 3d clouds: 145 fps with static cold sector tile: 95 fps when loaded, 6 (!) while loading with dynamical cold sector tile: 46 fps when loaded, 7 (!) while loading GIT build against the prebuilt OSG 2.9.6 coming with my 2.0.0 binary: empty sky: 230 fps with 3d clouds: 128 fps cold sector, static: 90 fps when loaded, 6 while loading cold sector dynamical: 48 fps when loaded, 8 while loading From this I conclude that what I'm seeing is not associated with OSG or the way I compile OSG. I also conclude that it's not related to performance issues of GIT in general - I get actually a better framerate than in 2.0.0 with GIT once things are loaded. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options - or maybe something else
From: thorsten.r...@jy... - 2010-11-12 10:13 I still have no real understanding why this is so, or why loading a large number of *identical* models into the scenery should take a long time (I would think that one can make use of the fact that there are really multiple copies of the same model around to speed things up, and while I was told that OSG does that automatically, this isn't what I observe) - if anyone can aid my understanding, please do so, it would be rather important. Not sure, maybe it is connected with an other issue we recently discovered. There are indeed some OSG operations which don't scale well. For example, OSG keeps a simple list of references at each shared model - so each shared model knows all nodes it is shared to. Adding a new member to the list takes almost no time - no matter on how large the list is. However, removing a shared model from a node can be very expensive - since it needs to search the entire list. The issue is negligible when a model isn't shared too often (say 5000 times). But it get's really, really ugly when a model has a lot more shares (10.000). This has recently caused another really bad performance issue. Enabling random scenery objects resulted in about 60.000 cows and about 30.000 horses being created (no kidding) to populate the FlightGear scenery. Creating these friendly animals was extremely efficient (no delay to be noticed). But when a scenery tile had to be removed, it had to disconnect a few thousand shares from the shared model - and each instance had to be looked-up in a list of about 60K elements... now guess what... this took 2-10 seconds per scenery tile. Removing several tiles could easily block the thread for a minute or two - meanwhile no new scenery tiles could be loaded... That's why we had to cull all the scenery animals for now. So, the implementation for loading shared objects is really efficient - but unloading a shared model can be really terrible - heavily depending on the number of shares. When you load new clouds - does this also involve dropping older clouds (removing some shares)? cheers, Thorsten -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and Paris
Paris has been a heavy scenery for a long time, but in the latest GIT it seems as if it is becoming unusable. I am getting 9 or 10 FPS in multithreading mode. A FGFS version of a couple of months ago dropped my FPS over Paris on the same system to about 12-15. Performance seems to have degraded a little bit. Paris scenery is not really well done- every texture file has a alpha layer in, even if it is not necessary. Another cause is the .xml-animation. The more .xml in the scenery the more worse fps is. In my eyes it is a big issue and prevents good and detailed sceneries. Unfortunately that's no bug as I have understood... To my mind, the issue is not if the scenery is efficiently done or not, but that it is handled different by present-dat GIT and by 2.0.0 (or older GIT), and that the newer versions become slower even with graphics goodies like urban shader are switched off. I *suspect* this may be related with the performance differences I see between local weather running with 2.0.0 or GIT - both Paris and local weather having to do with a large number of (non-random) models being present in the scenery. Doesn't help much in terms of a solution though... Cheers, * Thorsten -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and Paris
Hi Paris has been a heavy scenery for a long time, but in the latest GIT it seems as if it is becoming unusable. I am getting 9 or 10 FPS in multithreading mode. A FGFS version of a couple of months ago dropped my FPS over Paris on the same system to about 12-15. Performance seems to have degraded a little bit. In this instance I was not using local weather and the urban effect shader switched off. In other regions, my FPS rate is usually somewhere in the high thirtees to low seventees. A snapshot of the on screen statistics (in Debug) shows: Update: 23.44 Call: 25 46 Draw: 33.40 GPU: 40.34 Call: 4.66 Draw: 1.96 GPU: 1.66 How should these numbers be interpretated? Are they percentages, like in The GPU is 40.34% busy? m -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and Paris
On Sun, Oct 24, 2010 at 12:53 PM, fiers...@zonnet.nl wrote: A snapshot of the on screen statistics (in Debug) shows: Update: 23.44 Call: 25 46 Draw: 33.40 GPU: 40.34 Call: 4.66 Draw: 1.96 GPU: 1.66 How should these numbers be interpretated? Are they percentages, like in The GPU is 40.34% busy? They are in milliseconds. -- Csaba/Jester -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and Paris
Hi, Hi Paris has been a heavy scenery for a long time, but in the latest GIT it seems as if it is becoming unusable. I am getting 9 or 10 FPS in multithreading mode. A FGFS version of a couple of months ago dropped my FPS over Paris on the same system to about 12-15. Performance seems to have degraded a little bit. Paris scenery is not really well done- every texture file has a alpha layer in, even if it is not necessary. Another cause is the .xml-animation. The more .xml in the scenery the more worse fps is. In my eyes it is a big issue and prevents good and detailed sceneries. Unfortunately that's no bug as I have understood... Heiko Heiko -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and Paris
On Sunday 24 October 2010 05:02:23 Csaba Halász wrote: On Sun, Oct 24, 2010 at 12:53 PM, fiers...@zonnet.nl wrote: A snapshot of the on screen statistics (in Debug) shows: Update: 23.44 Call: 25 46 Draw: 33.40 GPU: 40.34 Call: 4.66 Draw: 1.96 GPU: 1.66 How should these numbers be interpretated? Are they percentages, like in The GPU is 40.34% busy? They are in milliseconds. And you can add them all up, invert them, and see the framerate: 1/(23.44+25.46+33.40+40.34+4.66+1.96+1.66)ms ~= 7.6 fps Ron -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options
On 10/2/2010 5:40 AM, thorsten.i.r...@jyu.fi wrote: To follow up on my previous message: Not so with my GIT binary: Loading of the initial cloud configuration brings me down to 4 fps, and every time (!) a cloud is loaded from the buffer my framerate drops from 34+ to something like 20+ for a moment - which makes the whole experience rather jerky. I have now made a series of tests to quantify the effect. The test situation is --disable-fullscreen --geometry=1200x900 --aircraft=ufo --airport=KINS --timeofday=noon --disable-real-weather-fetch 2.0.0 prebuilt: empty sky: 190 fps with 3d clouds: 128 fps with static cold sector tile: 90 fps when loaded, 34 while loading with dynamical cold sector tile: 45 fps when loaded, 30 while loading (note that this is *not* a fair comparison between standard 3d clouds and local weather clouds as the visibility and cloud view distance is rather different - not the point of the exercise) GIT built against my self-compiled OSG 2.9.10: empty sky: 234 fps with 3d clouds: 145 fps with static cold sector tile: 95 fps when loaded, 6 (!) while loading with dynamical cold sector tile: 46 fps when loaded,7 (!) while loading GIT build against the prebuilt OSG 2.9.6 coming with my 2.0.0 binary: empty sky: 230 fps with 3d clouds: 128 fps cold sector, static: 90 fps when loaded, 6 while loading cold sector dynamical: 48 fps when loaded, 8 while loading From this I conclude that what I'm seeing is not associated with OSG or the way I compile OSG. I also conclude that it's not related to performance issues of GIT in general - I get actually a better framerate than in 2.0.0 with GIT once things are loaded. But there is a dramatical difference in the impact on performance while new models are loaded (if you're flying, 30 fps vs. 6 fps is an issue...). That difference must be somewhere in the simgear or flightgear code. I can only stress that finding that difference and making GIT as fast as 2.0.0 in loading models will decide if local weather runs smoothly or not. At this point, the system itself is now fairly optimized and runs reasonably fast. Any help would be most welcome. Cheers, * Thorsten I've had some luck using the Intel compiler instead of gcc on processor heavy applications. It would be interesting to see what effect it may have on FG performance. http://software.intel.com/en-us/articles/non-commercial-software-download/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and compiler options
Hello, with significant help, I've recently succeeded to compile my own GIT binary. Initially this was very slow, in the mean time I've been told some flags for the compiler which I've been using to recompile OpenSceneGraph, Simgear and Flightgear which improved the available framerate by a factor two. Previously I've been using a pre-built Linux 2.0.0 binary and OpenSceneGraph 2.9.6 by Jon Stockill (of packages linked from the website, FlightGear-2.0.0-i686-1_slack11.0.tgz) which has been working very well for me. I've been developing, testing and optimizing the local weather package mainly with this binary. My self-compiled GIT binary and OSG 2.9.10 is now *almost* as fast - most of the time I guess it has about ~10-15% less framerate - with one important exception: Loading models into the scenery. Which means that as long as I have a given cloud configuration in the scenery, I reach even with wind-drift on above 34+ fps in a test situation (noon Cumulus layer around Las Vegas seen from the F-14b). But this changes whenever a cloud model is loaded. Local weather loads clouds by writing into the /models/ node of the property tree (pretty much the way the tanker.nas script generates a custom tanker). With my 2.0.0 binary, I have a noticeable drop down to 15+ fps when loading the initial configuration of ~1000 cloudlets. Once that is done, cloud are loaded from a buffer at a speed of 1 cloudlet per frame. This doesn't lead to any detectable drop in framerate. Not so with my GIT binary: Loading of the initial cloud configuration brings me down to 4 fps, and every time (!) a cloud is loaded from the buffer my framerate drops from 34+ to something like 20+ for a moment - which makes the whole experience rather jerky. I am sure that this difference is not caused by differences in the speed of writing from Nasal into the property tree (cloud drift writes several hundred properties per frame, but doesn't slow me down below 30 fps, loading a new model has far less writing processes) but by whatever the Flightgear core does after the /models/ node has been written to bring the model into the scenery. This always has been a bottleneck for me even in 2.0.0 which I have addressed by buffering the clouds - but with the GIT binary, it basically is the one issue which determines the speed of the local weather system. I'm pretty puzzled as to why this would be so, since it is working fine with my prebuilt 2.0.0 binary and OSG. Thus my question: Would Jon be so kind to let me know with what set of options the prebuilt slackware binaries and OSG libs were compiled, so that I can check if what I see is related to the way I compile? Or does anyone know if the code responsible for loading models into the scenery has been changed since 2.0.0 and if that could account for the difference in performance? Or does anyone have a different theory as to what is happening? (The good thing is that apparently there is a solution, because it does work smooth and well in 2.0.0) * Thorsten P.S.: I've also experienced that the Landmass effect shader is a complete show-stopper for my system - it brings me from 34+ fps down to 7 fps - is that normal? -- 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] Performance and initialization patch
Hi, weekly resubmit. New this week: o After scenery finishes loading: FGScenery::getPagerSingleton()-setMaximumNumOfObjectsToCompilePerFrame(1); Should help with excessive frame drops. Default is 4. o Integrated James Turner's fixes, thank you. o SGAtomic not longer used: big mem savings on win32 Usual content: o bigger zlib decompression buffer o nafree() returns if freeing NULL o throttle screen update rate on splash screen for single core machines o reduced memory usage for FGRunway o faster apt.dat, nav.dat awy.dat parsing My previous memory numbers were wrong, I was still using the buggy double taxiway allocation (I have 4 local copies of the code). With the SGAtomic changes and the reduced memory footprint of FGRunway the following memory usage was measured on ksfo (no random objects, win32), just running fgfs.exe, no params (i may have some non-standard preferences saved, they were the same for both runs anyway): original: 565MB this patch: 470MB Over some random terrain for which i have not downloaded terrain files and using ufo instead of c172: 338 231 This is after the splash screen disappears. The numbers oscilate +/- 10MB. It seems something is allocating and freeing memory just after loading. greetings, yon perf3.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi,
one little thing i was meaning to include but forgot. At the end of
fgMainLoop() add:
scenery_loaded = true;
}
if( ! scenery_loaded ) {
unsigned int tocompile =
FGScenery::getPagerSingleton()-getDataToCompileListSize();
unsigned int requests =
FGScenery::getPagerSingleton()-getFileRequestListSize();
char msg[60];
snprintf( msg, 59, loading scenery objects %2u / %2u, requests,
tocompile );
fgSplashProgress( msg );
}
fgRequestRedraw();
SG_LOG( SG_ALL, SG_DEBUG, );
}
For a nice little countdown of # of tiles left to load and compile.
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Dec 4, 2008 at 3:25 PM, Csaba Halász [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote: One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Somebody has recently switched some threading stuff over to OSG's classes, I wonder if we should throw out SGAtomic, SGReferenced, and SGSharedPtr in favor of OSG's implementation. Coincidentally, OpenThreads::Atomic doesn't have that align, it simply has a volatile long and presumably it works fine. -- Csaba/Jester Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. greetings, yon referenced.patch Description: Binary data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, i was testing on my local airport (coastal, less terrain) with ufo, let me test on inland airport (LEMD, madrid) with 172. Im running with the patch that reduces precision for fgrunway, no longer can we measure runway length in super-cords widths, only upto 10 nanometers ;) Memory (private bytes) measured with procexp.exe after scenery finishes loading. CVS: 499MB patched: 431MB hmm, over ocean: 291 361 hmm, i dont know what i measured before, maybe some other memory counter? my bad. Seems it is only saving around 70MB (on windows, unixes already have part of this memory saving). greetings, yon On Fri, Dec 5, 2008 at 5:28 PM, James Turner [EMAIL PROTECTED] wrote: On 5 Dec 2008, at 16:01, Yon Uriarte wrote: Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. Good gracious. 100MB? That seems almost impossibly large. This is a change that needs to be pretty widely tested, but it sounds like a great improvement. James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 4 Dec 2008, at 02:58, Yon Uriarte wrote:thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways>, it's wasteful.Well, see my version in that regard.Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies.By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192.I would prefer not to reduce precision - I don't think the memory savings warrant it, and at least on some machines, the compiler is forced to generate many float->double or double->float conversions. FGRunway is notefficientfor size, but it's not costing us anything in real terms - unlike the start up time. And, again, I have pending work in this area that makes all of these issues go away completely, so unless there's an immediate benefit for the 1.99.x release, I would focus on some other area.One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload.After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs?Can't comment on that, I'm on GCC 4.0 on Mac where SGAtomic is falling-back to pthreads :(Here's my patch (including yours) to src/Airports: fg-apt-perf-james.patch Description: Binary data Regards,James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Dec 4, 2008 at 10:01 AM, James Turner [EMAIL PROTECTED] wrote: On 4 Dec 2008, at 02:58, Yon Uriarte wrote: thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways, it's wasteful. Well, see my version in that regard. I see, it's overall nicer. Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies. By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. I would prefer not to reduce precision - I don't think the memory savings warrant it, and at least on some machines, the compiler is forced to generate many float-double or double-float conversions. FGRunway is not efficient for size, but it's not costing us anything in real terms - unlike the start up time. Around 30MB. Didnt know you where working on changing the airport load code. Going for 8.50? IMHO there is little point in keeping the runway length in doubles. It's seldom used, it's just putting pressure on the swap trigger. We let pass 30MB here, 30MB there, 2 seconds here, .8 there and it adds up. I try to consider a 1Ghz pentium 3 with 1GB RAM as an oldish machine target that may run fg. Not to nitpick, im glad i can give something to fg. The startup time is what catched my attention even before taking off the ground :) And, again, I have pending work in this area that makes all of these issues go away completely, so unless there's an immediate benefit for the 1.99.x release, I would focus on some other area. I will, thanks for the hint. I can test your airport code, profile it and gladly nitpick on it's memory/cpu use ;) I've been considering changing the load code for apt and nav to use strod. Apparently sometimes atof is implemented as a wrapper of strod (dinkumware.com, dont know what the man pages say). It would save the walking copy of the line for spliting and some atof overhead. It would produce the typical char *p inner loop :) But im having fun with the 3dclouds and osg, so maybe later. One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Can't comment on that, I'm on GCC 4.0 on Mac where SGAtomic is falling-back to pthreads :( Here's my patch (including yours) to src/Airports: thanks Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote: One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Somebody has recently switched some threading stuff over to OSG's classes, I wonder if we should throw out SGAtomic, SGReferenced, and SGSharedPtr in favor of OSG's implementation. Coincidentally, OpenThreads::Atomic doesn't have that align, it simply has a volatile long and presumably it works fine. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways, it's wasteful. Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies. By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Thanks again, attached is a patch for the patch. May I ask for your patch? greetings, yon On Thu, Dec 4, 2008 at 2:38 AM, James Turner [EMAIL PROTECTED] wrote: On 1 Dec 2008, at 18:20, James Turner wrote: I will apply and test, sadly I am in the same situation as you for getting patches applied :) I've tested the apt loader / string split / patch, and everything seems to work - though I've complicated things by refactoring the runway / taxiway creation, to fix some style issues, and resolve a couple of problems: taxiways don't need a reciprocal created (and it's wasteful to do so), and runways weren't getting their airport set, which crashed some local code of mine. Regards, James perf2.patch.gz Description: GNU Zip compressed data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Sun, Nov 30, 2008 at 12:56 AM, Tim Moore [EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. No. Your request to don't use it in the global constructors is not sufficient. Shouldnt matter too much performance wise anyway :) I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) greetings, yon loader.patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 1 Dec 2008, at 18:00, Yon Uriarte wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) I will apply and test, sadly I am in the same situation as you for getting patches applied :) James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi On Mon, Dec 1, 2008 at 7:20 PM, James Turner [EMAIL PROTECTED] wrote: On 1 Dec 2008, at 18:00, Yon Uriarte wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) I will apply and test, sadly I am in the same situation as you for getting patches applied :) James haha, thank you. What's your patch about? Maybe we can swap patch tests :) yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Mon, Dec 1, 2008 at 7:00 PM, Yon Uriarte [EMAIL PROTECTED] wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) did some timings on the throttle patch to try and market it :) I got some unexpected results: All times in ms, dual-core pentium E2xxx @3.1GHz Affinity set to simulate single-core with: start /affinity 0x1 /B fgfs ... Throttle at 15fps throttled, no random objects, no affinity. 4096 4078 4074 not throttled, no random objects, no affinity 3029 3217 3012 throttled, no random objects, affinity 0x1 5498 5435 5457 not throtled, no random objects, affinity 0x1 4556 4502 4482 throttled, enabled random objects, no affinity 30009 29532 29005 29988 not throttled, enabled random objects, no affinity 38285 37927 37958 throttled, enabled random objects, affinity 0x1 33749 33518 34116 not throttled, enabled random objects, affinity 0x1 61120 57412 58443 it is faster for random objects (target case), but slower for all other cases. I suspect the osgDB threads are blocking waiting for the frame to upload their display lists. Anyway, throttled to 50fps now I get: throttled 50 , no random objects, no affinity 3176 3187 3168 throttled 50 , random objects, affinity 0x1 38455 37583 38273 Please set the frame limiter to 50, not15, when testing, I'll set it to that in next week's patch. yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Yon Uriarte wrote: Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. No. Your request to don't use it in the global constructors is not sufficient. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, it seems this message was deleted (over 40k). I cant find it on the archives so im resending it now with a compressed patch. Please ignore if this is a repost. -- this patch tries to speed up airways laoding. The strutils funcions are meaningfully commented and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. flightgear-patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 greetings, yon On Fri, Nov 28, 2008 at 11:09 AM, Yon Uriarte [EMAIL PROTECTED] wrote: Hi, it seems this message was deleted (over 40k). I cant find it on the archives so im resending it now with a compressed patch. Please ignore if this is a repost. -- this patch tries to speed up airways laoding. The strutils funcions are meaningfully commented and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. fg.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On Fri, Nov 28, 2008 at 10:18 AM, Yon Uriarte wrote: Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 Am I misreading your stats? There doesn't seem to be any significant different between your two sets of timing data (?) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
hi, those are 2 consecutive samples of the new navaid.dat parser. Compare with the times in the previous posts. It has gone down from 520msec to 350msec. Not a big difference on a fast machine, but it was a very easy change. On slower machines it should add up. greetings, yon On Fri, Nov 28, 2008 at 5:25 PM, Curtis Olson [EMAIL PROTECTED] wrote: On Fri, Nov 28, 2008 at 10:18 AM, Yon Uriarte wrote: Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 Am I misreading your stats? There doesn't seem to be any significant different between your two sets of timing data (?) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi,
another little detail. In zfstream.cxx the input buffer for reading
buffered .gz files is set at page_size (4k). It is my understanding this
means files will be read at 4k chunks (uncompressed 4k). By changing the
multiplier to 16 (64k) or even 64 i could unscientifically measure a small
gain. I believe gzstream is used for terrain loading, too. I guess a value
of 16*page_size should be adecuate, not too small, small enough that it
might stay in the cache for the caller to process. This should save on
system calls, too.
Non scientific measurements, twice for each size:
original, 1 page buffer:
Airport load time: 1769
Metar load time: 7
Navaid load time: 349
Airway load time: 726
Airport load time: 1770
Metar load time: 7
Navaid load time: 348
Airway load time: 728
istream.gz buffer from 1 to 16 pages size
Airport load time: 1746
Metar load time: 7
Navaid load time: 343
Airway load time: 716
Airport load time: 1742
Metar load time: 8
Navaid load time: 343
Airway load time: 724
at 64 pages
Airport load time: 1728
Metar load time: 7
Navaid load time: 344
Airway load time: 720
Airport load time: 1736
Metar load time: 7
Navaid load time: 345
Airway load time: 728
Patch:
Index: zfstream.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/zfstream.cxx,v
retrieving revision 1.5
diff -u -r1.5 zfstream.cxx
--- zfstream.cxx 25 Jul 2008 18:35:42 - 1.5
+++ zfstream.cxx 28 Nov 2008 17:15:05 -
@@ -42,7 +42,7 @@
ibuffer(0)
{
// try {
-ibuf_size = page_size / sizeof(char);
+ibuf_size = 16*(page_size / sizeof(char));
ibuffer = new char [ibuf_size];
// } catch (...) {
//delete [] ibuffer;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 26 Nov 2008, at 12:19, James Turner wrote: strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. Just had a thought here - it should be possible to use std::vector::swap() to pass in std::vectorFGRunway*, and avoid the ugly 'count' arguments. I'll do up a patch for this today/tonight. I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 27 Nov 2008, at 11:50, Yon Uriarte wrote: I changed it a bit, too. Now it passes the runways to the constructor and addRunways is private. But using swap sounds like the solution. It'll need 2 vectors in the apt.dat main loop, one with runways, the other one with taxis. Right, I think that makes sense. I sort of prefer to have a: void FGAirport::addRunwaysAndTaxiways(std::vectorFGRunway* aRunways, std::vectorFGRunway* aTaxiways) rather than constructor arguments, but that's a personal dislike of constructors with many arguments. Either way is acceptable! I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Changed the name to split_inplace and patching airways parsing to use it. Still testing and timing. Possibly will look at the fix parsing, too, it's slowish. Fair enough. Again, I may be changing how the data is loaded in the future, but short term gains are also good. Thanks, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, commenting inline. Im still programming a bit and measuring times. Patch later. On Wed, Nov 26, 2008 at 2:26 PM, Melchior FRANZ [EMAIL PROTECTED] wrote: Hi, * Yon Uriarte -- Wednesday 26 November 2008: this is a patch to speed up startup times and some other misc things. Thanks for taking care of that. Startup time is really a problem, made worse by the fact that one has to restart fgfs to use another aircraft. I'll leave commenting on the nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. I've renamed the functions and added meaningful comments. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. No, i dont think they should keep doing that. In the context of the file it's written in (strutils.cxx) you can easily compare the 2 functions and calculate in your head why the others are a cluster thing. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) WTF?? why? we are adults. Whatever, adult words removed. BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. Nothing i can do about that, let the CVS commiters pass a replace over the files. MSVS is a hard master. Or is there an option to tell it not to mess with my spaces? m. greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
- Yon Uriarte a écrit : Nothing i can do about that, let the CVS commiters pass a replace over the files. MSVS is a hard master. Or is there an option to tell it not to mess with my spaces? Tools Options Text editor C/C++ Tabs -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Nov 27, 2008 at 9:53 AM, James Turner [EMAIL PROTECTED] wrote: On 26 Nov 2008, at 12:19, James Turner wrote: strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. Just had a thought here - it should be possible to use std::vector::swap() to pass in std::vectorFGRunway*, and avoid the ugly 'count' arguments. I'll do up a patch for this today/tonight. I changed it a bit, too. Now it passes the runways to the constructor and addRunways is private. But using swap sounds like the solution. It'll need 2 vectors in the apt.dat main loop, one with runways, the other one with taxis. I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Changed the name to split_inplace and patching airways parsing to use it. Still testing and timing. Possibly will look at the fix parsing, too, it's slowish. Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, this patch tries to speed up airways laoding. The strutils funcions are meaningfully commened and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED]wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. FlightGear - Copy (2).patch Description: Binary data SimGear - Copy (2).patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and initialization patch
Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: nasal/misc.h: If p == 0 return, else call free(p). Dont go into the malloc lib for nothing, probably free() does this check 1st thing in most implementations, no need to test the malloc library. p == 0 happens, checked with debugger. logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? ViewPartitionNode, CameraGroup: Small compile fix for a OSG version with float matrices, instead of double. Tried to compile with float matrices to see if it affects speed, but the quantization is visible (aprox .5m) and the airplane jitters horribly. main.cxx: While showing the splash screen, limit the frame rate. I was getting 200fps at the splash screen, which is pointless wasteful, specially on single-core machines. On multicore one core is pegged at 100%, another is loading tiles. If you run with VBLANK on, on a fast single-core machine, it may not matter too much. Anyway, 15Hz redraws should be enough, quite possibly as low as 5Hz could be acceptable. Older computer owners should notice a difference. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) The most important changes are the apt.dat optimization, the logstream optimization and the splash screen throttling. On this 3Ghz dual core intel E2160 with hot disk-caches and --disable-random-objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. Going forward another big config issue I see is --enable-random-objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random-objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. regards, yon FlightGear - Copy.patch Description: Binary data SimGear - Copy.patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, * Yon Uriarte -- Wednesday 26 November 2008: this is a patch to speed up startup times and some other misc things. Thanks for taking care of that. Startup time is really a problem, made worse by the fact that one has to restart fgfs to use another aircraft. I'll leave commenting on the nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 26 Nov 2008, at 11:14, Yon Uriarte wrote: Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) Sounds good to me. strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? I suspect this is paranoia due to some of the more exotic OSG threading modes being less well tested. I believe I can be over-riden by the OSG_THREADING environment variable in any case. Tim Moore can hopefully say for sure. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) This is 'my' file, it's new in the codebase and could easily contain silly things. You patch only adds an operator, so I'm not sure if it's needed or not. dual core intel E2160 with hot disk-caches and --disable-random- objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. I would hold off airways unless you have an abundance of time (or look at random objects first), or if it's a quick change, since I'm planning some more drastic changes in that area, possibly including a file format change. If it's a quick win, go for it, of course. Going forward another big config issue I see is --enable-random- objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random- objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. Thanks for doing this, it's much appreciated. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
On Thursday 20 December 2007 01:07, Shad Young wrote: Hi all, Again not sure if I should post this to the users list. I have been experimenting with the latest FG 1.0.0 on Win32 (XP SP2) and am having some rather significant frame dropping. FPS on or near the ground at San Fran in all AC often results in long pauses and jumps, with regular stutters. FPS are all over the map, from 60fps to 1 frame every couple of seconds. I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. Are there specific tweaks that can be made, or are there some settings that should be turned off? I have tried to reset to default but then FG launcher seems to crash. I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) TIA Shad Are you getting this at KSFO? It takes nearly a minute after starting FG at KSFO for my system to settle down into a stable frame-rate due to all the models being loaded. During this time I see the same wide variations in frame-rate as you - 60~1 fps. Do you get the same results if you start at a much simpler airport some distance away from KSFO? LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
Frederic Bouvier wrote: Selon Shad Young : I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) Ok, I found the solution to one problem. The uninstall leaves the flightgear.org folder in Application Data within Documents and Settings. Manually deleting this is necessary for a clean re-install. There is also de Default button to come back to default settings -Fred Hi Fred, thanks for the reply. Sadly, clicking on the Default button causes the launcher to crash. But I found the hidden folder in Application Data. Deleting it brought me back to defaults. Cheers Shad - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance issues in Win32
Hi all, Again not sure if I should post this to the users list. I have been experimenting with the latest FG 1.0.0 on Win32 (XP SP2) and am having some rather significant frame dropping. FPS on or near the ground at San Fran in all AC often results in long pauses and jumps, with regular stutters. FPS are all over the map, from 60fps to 1 frame every couple of seconds. I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. Are there specific tweaks that can be made, or are there some settings that should be turned off? I have tried to reset to default but then FG launcher seems to crash. I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) TIA Shad - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don't know where it is on windows but on Linux there is an xml in $HOME/.fgfs/autosave.xml and for each aircraft $HOME/.fgfs/aircraft-data/*.xml. Regards, Arvid Norlander Shad Young wrote: Hi all, Again not sure if I should post this to the users list. I have been experimenting with the latest FG 1.0.0 on Win32 (XP SP2) and am having some rather significant frame dropping. FPS on or near the ground at San Fran in all AC often results in long pauses and jumps, with regular stutters. FPS are all over the map, from 60fps to 1 frame every couple of seconds. I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. Are there specific tweaks that can be made, or are there some settings that should be turned off? I have tried to reset to default but then FG launcher seems to crash. I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) TIA Shad -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHacY6WmK6ng/aMNkRChWQAJ4uJ5QqnLH0qauv0v0NYzjuoGdbCQCfWJmE eOzOb63ujTaipdBfgCJ9+qc= =LWPp -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don't know where it is on windows but on Linux there is an xml in $HOME/.fgfs/autosave.xml and for each aircraft $HOME/.fgfs/aircraft-data/*.xml. Regards, Arvid Norlander Shad Young wrote: Hi all, Again not sure if I should post this to the users list. I have been experimenting with the latest FG 1.0.0 on Win32 (XP SP2) and am having some rather significant frame dropping. FPS on or near the ground at San Fran in all AC often results in long pauses and jumps, with regular stutters. FPS are all over the map, from 60fps to 1 frame every couple of seconds. I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. Are there specific tweaks that can be made, or are there some settings that should be turned off? I have tried to reset to default but then FG launcher seems to crash. I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) TIA Shad Ok, I found the solution to one problem. The uninstall leaves the flightgear.org folder in Application Data within Documents and Settings. Manually deleting this is necessary for a clean re-install. Cheers Shad - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
Selon Shad Young : I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) Ok, I found the solution to one problem. The uninstall leaves the flightgear.org folder in Application Data within Documents and Settings. Manually deleting this is necessary for a clean re-install. There is also de Default button to come back to default settings -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance monitoring
Title: Performance monitoring Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? Jon --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk0709&30571642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
On Thu, 18 May 2006 10:58:26 -0500, Berndt, wrote in message [EMAIL PROTECTED]: Performance monitoring Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? ..in the god old days way I use top, but there are way more ways: [EMAIL PROTECTED]:/var/www/mmc/BT/2006.0509 $ apt-cache search Performance \ monitoring beancounter - A stock portfolio performance monitoring tool libpfm3-dev - Performance Monitor Unit (PMU) -- development files maxdb-dbanalyzer - A performance monitoring tool for MaxDB databases oprofile - system-wide profiler for Linux systems pfmon - Tool for using Performance Monitoring Unit(PMU) [EMAIL PROTECTED]:/var/www/mmc/BT/2006.0509 $ apt-cache search Performance \ monitoring acidlab-doc - Analysis Console for Intrusion Databases (documentation) beancounter - A stock portfolio performance monitoring tool kpowersave - frontend to powersave for setting user specific policies libpfm3-dev - Performance Monitor Unit (PMU) -- development files libprelude-dev - Hybrid Intrusion Detection System [Development files] libprelude2 - Hybrid Intrusion Detection System [Base library] maxdb-dbanalyzer - A performance monitoring tool for MaxDB databases mytop - top like query monitor for MySQL oprofile - system-wide profiler for Linux systems pfmon - Tool for using Performance Monitoring Unit(PMU) prelude-lml - Hybrid Intrusion Detection System [Log Monitoring Lackey] slmon - A simple S-Lang based system performance monitor [EMAIL PROTECTED]:/var/www/mmc/BT/2006.0509 $ ..'apt-cache --full search Performance monitoring |less' for the gory details if you're on a Debian box, ' man top ' or 'info top' should work on all GNU/Linux boxes. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
Jon S. Berndt wrote: Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? It's probably best to start with gprof. Add a -pg argument to the compiler flags for the application, run it, and then use the gprof program to eamine the resulting gmon.out file. Note that performance tuning is a black art, and that the numbers you see are going to be lying to you in subtle ways, especially if you have the optimizer turned on. And you probably aren't going to be able to use it to profile a real time application (like FlightGear) very well at all. Andy --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
On Thursday 18 May 2006 16:58, Berndt, Jon S wrote: [HTML snipped...] Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? Is it 'time' you're thinking of? LeeE --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
On Thu, 18 May 2006, Berndt, Jon S wrote: Can anyone tell me what the name of the routines is that allows one to determine the performance details of a Linux application? Depending on the application it might work to compile it with profiling enabled using the gcc flag -pg: -pg Generate extra code to write profile information suitable for the analysis program gprof. You must use this option when compiling the source files you want data about, and you must also use it when linking. IIRC there might be problems if the program is multithreaded or uses complex shared libraries(?). When it works the information is often very useful. /Anders -- Luck is my middle name, said Rincewind, indistinctly. Mind you, my first name is Bad. -- (Terry Pratchett, Interesting Times) - | Anders Gidenstam | Tel: 031-230645 070-296 1707 | | Email: anders(at)gidenstam.org | WWW: http://www.gidenstam.org| - (Note to Outlook users: Click forward/vidarebefodra to make any attachments visible.) --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] performance and appearance issues with point sprites
Jean-Yves Lefort wrote: A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight: See the attached patch (I think point-sprite and line-smooth should be disabled by default). Why, because an ancient video card can't display it properly? If we go that way then please disable fog-nicest also because my O2 can't handle it... It might be best to be able to turn it off at the command line instead. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator http://www.cafepress.com/fgfs_flightsim FlightGear Art --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] performance and appearance issues with point sprites
On Mon, 06 Mar 2006 09:30:08 +0100 Erik Hofman [EMAIL PROTECTED] wrote: Jean-Yves Lefort wrote: A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight: See the attached patch (I think point-sprite and line-smooth should be disabled by default). Why, because an ancient video card can't display it properly? s/ancient/low end/ If we go that way then please disable fog-nicest also because my O2 can't handle it... It might be best to be able to turn it off at the command line instead. Maybe enable line smoothing and disable point sprites. If someone starts fg for the first time and gets dim blinking pixels as lights, he might end up thinking that the software is bogus. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp3A7c6vXsvI.pgp Description: PGP signature
[Flightgear-devel] performance and appearance issues with point sprites
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false true2 steady thick points [1]
truefalse 11 dim and blinking pixels [2]
truetrue11 steady thin points [3]
[1] Identical to CVS 20060126.
[2] Nice for christmas, but otherwise completely broken. This is what
I get without the patch.
[3] Best attempt at looking like a real airport, I'd use this on a
more powerful system.
Enabling line-smooth removes about 7 fps from these figures.
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.44
diff -u -r1.44 renderer.cxx
--- src/Main/renderer.cxx 21 Feb 2006 01:19:19 - 1.44
+++ src/Main/renderer.cxx 5 Mar 2006 05:29:14 -
@@ -222,8 +222,9 @@
glFrontFace ( GL_CCW );
// Just testing ...
-if ( SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
- SGIsOpenGLExtensionSupported(GL_NV_point_sprite) )
+if ( (SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
+ SGIsOpenGLExtensionSupported(GL_NV_point_sprite))
+fgGetBool(/sim/rendering/point-sprite))
{
GLuint handle = thesky-get_sun_texture_id();
glBindTexture ( GL_TEXTURE_2D, handle ) ;
@@ -232,7 +233,8 @@
// glEnable(GL_POINT_SMOOTH);
glPointSpriteIsSupported = true;
}
-glEnable(GL_LINE_SMOOTH);
+if ( fgGetBool(/sim/rendering/line-smooth) )
+glEnable(GL_LINE_SMOOTH);
// glEnable(GL_POLYGON_SMOOTH);
glHint(GL_POLYGON_SMOOTH_HINT, GL_DONT_CARE);
glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE);
pgprMEdUHNju5.pgp
Description: PGP signature
