Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
Curtis, Finally getting somewhere on this issue. Using the Seahawk with Apr source and data, performance is very satisfactory. Generally good frame rates, with just the odd stagger, which judging by the odd video I have seen on YouTube, seems to be the general case. Using cvs-head source and data, with everything else the same, severe staggering, poor frame rates, virtually unusable. Using cvs-head source, but reverting the data to Apr, although that breaks quite a bit of fg, framerates are restored, and staggers are back to normal. So, I think we are on to something with the nasal hypothesis. I'm now trying to eliminate the scripts one by one. And kicking myself for not getting here faster. Vivian -Original Message- From: Curtis Olson [mailto:[EMAIL PROTECTED] Sent: 22 September 2008 23:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system On Mon, Sep 22, 2008 at 5:23 PM, James Turner wrote: On 22 Sep 2008, at 23:05, Vivian Meazza wrote: A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. Well, being selfish, one around the start of August would rule my changes in or out - but if you're slogging through the binary search, I'll leave you to it. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK is hasn't been touched in a good long time. Here's another idea to toss into the mix ... What aircraft is being flown in these tests? If hash.c looks like a hotspot, that could also be triggered by an aircraft that had a lot of new nasal code added. Or it could be newly added default system nasal code? I don't know how much of FlightGear functions anymore without nasal, but disabling the default nasal directory and picking an aircraft with little or no embedded nasal code might also be an interesting test. We could possibly have crossed a threshold in terms of the amount of nasal code used for some particular aircraft? Regards, 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] FlightGear on 32 bits versus 64 bits system
On mercredi 24 septembre 2008, Vivian Meazza wrote: Curtis, Finally getting somewhere on this issue. Using the Seahawk with Apr source and data, performance is very satisfactory. Generally good frame rates, with just the odd stagger, which judging by the odd video I have seen on YouTube, seems to be the general case. Using cvs-head source and data, with everything else the same, severe staggering, poor frame rates, virtually unusable. Using cvs-head source, but reverting the data to Apr, although that breaks quite a bit of fg, framerates are restored, and staggers are back to normal. So, I think we are on to something with the nasal hypothesis. I'm now trying to eliminate the scripts one by one. And kicking myself for not getting here faster. Vivian -Original Message- From: Curtis Olson [mailto:[EMAIL PROTECTED] Sent: 22 September 2008 23:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system On Mon, Sep 22, 2008 at 5:23 PM, James Turner wrote: On 22 Sep 2008, at 23:05, Vivian Meazza wrote: A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. Well, being selfish, one around the start of August would rule my changes in or out - but if you're slogging through the binary search, I'll leave you to it. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK is hasn't been touched in a good long time. Here's another idea to toss into the mix ... What aircraft is being flown in these tests? If hash.c looks like a hotspot, that could also be triggered by an aircraft that had a lot of new nasal code added. Or it could be newly added default system nasal code? I don't know how much of FlightGear functions anymore without nasal, but disabling the default nasal directory and picking an aircraft with little or no embedded nasal code might also be an interesting test. We could possibly have crossed a threshold in terms of the amount of nasal code used for some particular aircraft? Regards, Curt. Only, a question: Does the stutter comes up when testing with the c172p (over KSFO for instance) , that AC has not Nasal script. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] FlightGear on 32 bits versus 64 bits system
Vivian Meazza wrote: I'm profiling with absolutely _everything_ disabled (including replay). _If_ that had shown that the stagger went away I would have reintroduced features one by one. But I can't even get that far atm. Still trying though, and still trying to identify the cause. I note, however, that not long ago we had a very good solution, so it's something we have done, and relatively recently. Ok, I was under the impression I saw the same problem here and turning off ai models cured it for me (a tenfold in framerate improvement at KSFO). This might have something to do with new taxiway routes and old scenery since I do see the aircraft parked at the roof of the terminal building there.. Anyhow, too bad this doesn't solve the problem for you. Erik - 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] FlightGear on 32 bits versus 64 bits system
Curtis Olson wrote: What aircraft is being flown in these tests? If hash.c looks like a hotspot, that could also be triggered by an aircraft that had a lot of new nasal code added. Or it could be newly added default system nasal code? I don't know how much of FlightGear functions anymore without nasal, but disabling the default nasal directory and picking an aircraft with little or no embedded nasal code might also be an interesting test. We could possibly have crossed a threshold in terms of the amount of nasal code used for some particular aircraft? The F-16, for one (the one I test with the most), doesn't use much nasal code (and neither do for instance the Fokker-100 and T-38). I must say, I don't seem to see the problems others are reporting. I thought I was .. but it turned out to be a different problem after all. Erik - 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] FlightGear on 32 bits versus 64 bits system
Vivian Meazza wrote: Er ... couple of words spring to mind there - grandmother and eggs :-). But I know that you are trying to help. Alright, I'm just about to lay down activities for FlightGear for the second time (and now for good) because of this statement. There was a time where i was the *only* patch reviser and committer and have probably spent more time browsing the code than any other active developer. I realize that the move to osg has put me behind a bit but setting me aside as an infant rather than discussing the problem is unacceptable. Erik - 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] FlightGear on 32 bits versus 64 bits system
Erik Hofman wrote: Vivian Meazza wrote: Er ... couple of words spring to mind there - grandmother and eggs :-). But I know that you are trying to help. Alright, I'm just about to lay down activities for FlightGear for the second time (and now for good) because of this statement. There was a time where i was the *only* patch reviser and committer and have probably spent more time browsing the code than any other active developer. I realize that the move to osg has put me behind a bit but setting me aside as an infant rather than discussing the problem is unacceptable. I think you misunderstand the sense of the idiom teaching your grandmother to suck eggs. It implies nothing about the maturity of the teacher. Vivian meant that you were treating him like a child -- that's the teaching an elderly person to suck eggs part -- but I think between his smiley and his I know that you are trying to help comment it is clear that he is joking. In any event, do stick around and learn more about the OSG parts, as more eyeballs there are always welcome. 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] FlightGear on 32 bits versus 64 bits system
Tim Moore wrote: I think you misunderstand the sense of the idiom teaching your grandmother to suck eggs. It implies nothing about the maturity of the teacher. Vivian meant that you were treating him like a child -- that's the teaching an elderly person to suck eggs part -- but I think between his smiley and his I know that you are I'm still not completely convinced, but not being a native English speaker I'll take your word for it. I'm sorry about it then, but could we please leave these kind of expressions out of the discussion in the future; being personal like this without being 100% sure the other side knows exactly what is meant can set bad blood. Again, sorry for the reaction. Erik - 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] FlightGear on 32 bits versus 64 bits system
Tim Moore wrote : Vivian Meazza wrote: Er ... couple of words spring to mind there - grandmother and eggs :-). But I know that you are trying to help. I thought if was related to the chicken and egg problem, but I didn't see why grandmother should be involved ;-) I think you misunderstand the sense of the idiom teaching your grandmother to suck eggs. It implies nothing about the maturity of the teacher. Vivian meant that you were treating him like a child -- that's the teaching an elderly person to suck eggs part -- but I think between his smiley and his I know that you are trying to help comment it is clear that he is joking. Thank you for the explanation. -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] FlightGear on 32 bits versus 64 bits system
On mercredi 17 septembre 2008, gerard robin wrote: Hello, Running without any problem with FG on a 32 bits computer (which my usual computer) recently, I have had to build FlightGear on a 64 bit computer with FC9. Both computers have the same GPU (Nvidia 7800 GS AGP 8). I was disappointed with the result FG works with a huge Jitter, like we had in the past, which is now , to me, solved (32 bits environment). Does anybody has got a similar problem ? Where do i must look for to solve the problem ? did i forgot some parameters with ./configure and/or make ? Cheers NB:Openscenegraphe had been automatically built 64 bits ( lib64 library). Again on that topic, i was wrong about 64 bit , which has nothing to do with the stutter/jitter within FG. The explanation is: the computer (a dual core AMD 64 x2 6400) which is involved has the Linux operating system FC9, which, unfortunately, include the last KDE desktop 4.1. That desktop eat some GL resources due to the desktop effects, and probably conflicts with any other applications which want GL, Tested, Celestia.. and FlightGear, the result is a huge stutter . Fortunately it is possible to deactivate the desktop-effect. And everything is coming back right and smooth. Cheers BTW I don't know if that problem is FC9 only, or if it happen to any Linux operating which include KDE 4.1. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] FlightGear on 32 bits versus 64 bits system
On Monday 22 September 2008 12:16:13 gerard robin wrote: Again on that topic, i was wrong about 64 bit , which has nothing to do with the stutter/jitter within FG. That's true (since we've seen the same stuttering on 32 bit machines as well). However, even though in your case disabling fancy effects appears to cure your system it seems there is something in FG causing a distinct stutter, happening around once per second, irrespective of framerate. On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the stutter is basically undetectable under most circumstances, but very noticeable with the Brest photo scenery and slightly less so when using a highly-detailed model over another highly-populated scenery area. It seems to me to have been a fairly recent thing, which seemed to show up here around the same time as James' patches were committed (though I'm not certain enough to blame them, and haven't had time to revert back and build again.) It also doesn't appear to be caused by nasal and occurs whether or not AI traffic or the traffic-manager, or multiplayer are enabled. Nobody else seeing the same thing? - 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] FlightGear on 32 bits versus 64 bits system
On Mon, Sep 22, 2008 at 7:54 AM, AJ MacLeod wrote: On Monday 22 September 2008 12:16:13 gerard robin wrote: Again on that topic, i was wrong about 64 bit , which has nothing to do with the stutter/jitter within FG. That's true (since we've seen the same stuttering on 32 bit machines as well). However, even though in your case disabling fancy effects appears to cure your system it seems there is something in FG causing a distinct stutter, happening around once per second, irrespective of framerate. On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the stutter is basically undetectable under most circumstances, but very noticeable with the Brest photo scenery and slightly less so when using a highly-detailed model over another highly-populated scenery area. It seems to me to have been a fairly recent thing, which seemed to show up here around the same time as James' patches were committed (though I'm not certain enough to blame them, and haven't had time to revert back and build again.) It also doesn't appear to be caused by nasal and occurs whether or not AI traffic or the traffic-manager, or multiplayer are enabled. Nobody else seeing the same thing? I am hearing a pretty distinct glitch in the audio about once per second ... it's not so much of a hard break, but disruption in continuity. I'm not sure if this is related to a pause in FlightGear, or the openal drivers on Fedora 9, or what? The once per second audio glitch seems to be more distinct on lower performance CPU's. (Referring to our cvs development version of course.) Regards, 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] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Curtis Olson wrote: I am hearing a pretty distinct glitch in the audio about once per second ... it's not so much of a hard break, but disruption in continuity. I'm not sure if this is related to a pause in FlightGear, or the openal drivers on Fedora 9, or what? The once per second audio glitch seems to be more distinct on lower performance CPU's. (Referring to our cvs development version of course.) Regards, Curt. Yes, disruption in continuity i hear it too , with my usual 32 bit system (fc8) ., and with the other 64 bit system (fc9). -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] FlightGear on 32 bits versus 64 bits system
AJ wrote On Monday 22 September 2008 12:16:13 gerard robin wrote: Again on that topic, i was wrong about 64 bit , which has nothing to do with the stutter/jitter within FG. That's true (since we've seen the same stuttering on 32 bit machines as well). However, even though in your case disabling fancy effects appears to cure your system it seems there is something in FG causing a distinct stutter, happening around once per second, irrespective of framerate. On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the stutter is basically undetectable under most circumstances, but very noticeable with the Brest photo scenery and slightly less so when using a highly-detailed model over another highly-populated scenery area. It seems to me to have been a fairly recent thing, which seemed to show up here around the same time as James' patches were committed (though I'm not certain enough to blame them, and haven't had time to revert back and build again.) It also doesn't appear to be caused by nasal and occurs whether or not AI traffic or the traffic-manager, or multiplayer are enabled. Nobody else seeing the same thing? As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Vivian - 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] FlightGear on 32 bits versus 64 bits system
Hi Vivian, Vivian Meazza wrote : As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -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] FlightGear on 32 bits versus 64 bits system
Hi Fred, Fred wrote: Hi Vivian, Vivian Meazza wrote : As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -Fred I use LTProf here: http://www.lw-tech.com/ Small charge, but it seems to give some useful/meaningful results Vivian - 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] FlightGear on 32 bits versus 64 bits system
Vivian Meazza wrote: As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. One hint, try running with: --disable-ai-models Erik - 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] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Vivian Meazza wrote: Hi Fred, Fred wrote: Hi Vivian, Vivian Meazza wrote : As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -Fred I use LTProf here: http://www.lw-tech.com/ Small charge, but it seems to give some useful/meaningful results Vivian Are we sure that we are talking about the same topic and the same problem , as far i understand, = on one side, the cause is coming from compilation under an MS windows OS, = on the other side, there is problem within FG itself like described by AJ and Curt. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] FlightGear on 32 bits versus 64 bits system
Hi Erik To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system Vivian Meazza wrote: As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. One hint, try running with: --disable-ai-models Er ... couple of words spring to mind there - grandmother and eggs :-). But I know that you are trying to help. I'm profiling with absolutely _everything_ disabled (including replay). _If_ that had shown that the stagger went away I would have reintroduced features one by one. But I can't even get that far atm. Still trying though, and still trying to identify the cause. I note, however, that not long ago we had a very good solution, so it's something we have done, and relatively recently. Vivian - 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] FlightGear on 32 bits versus 64 bits system
gerard On lundi 22 septembre 2008, Vivian Meazza wrote: Hi Fred, Fred wrote: Hi Vivian, Vivian Meazza wrote : As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -Fred I use LTProf here: http://www.lw-tech.com/ Small charge, but it seems to give some useful/meaningful results Vivian Are we sure that we are talking about the same topic and the same problem , as far i understand, = on one side, the cause is coming from compilation under an MS windows OS, = on the other side, there is problem within FG itself like described by AJ and Curt. AJ and I _think_ we are talking about the same problem. We might not be, although the description of the symptoms, which we have discussed many times, seems to be the same. The underlying cause might not be the same. It might be the code, the compiler, the OS. We don't know, which is why we need some more evidence. It might be different causes for AJ and for me. What we do know is that we had a much better solution a while back. Vivian - 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] FlightGear on 32 bits versus 64 bits system
On 22 Sep 2008, at 22:25, Vivian Meazza wrote: AJ and I _think_ we are talking about the same problem. We might not be, although the description of the symptoms, which we have discussed many times, seems to be the same. The underlying cause might not be the same. It might be the code, the compiler, the OS. We don't know, which is why we need some more evidence. It might be different causes for AJ and for me. What we do know is that we had a much better solution a while back. Since this might be my fault, I'll say that as far as I know (of course I could be very, very wrong), none of my changes should have a noticeable performance impact (yet). For example, the marker-beacon instrument searches for nearby navaids of a certain type, and in the future I might change how the search is implemented, but right now all the old search methods are being used. Of course I could easily have made a mistake. The best solution is a binary search of CVS - rewind to a date which is 'known good' and the keep stepping forwards / back by half the time interval and checking- out / rebuilding / testing. Generally it will only take 4-8 iterations of this (tedious) process to narrow it down to a day, at which point we can see how I screwed up :) It would also be good to know if everyone sees this issue (or some variation), or only certain OS-es / people with slower machines / etc 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] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Vivian Meazza wrote: gerard On lundi 22 septembre 2008, Vivian Meazza wrote: Hi Fred, Fred wrote: Hi Vivian, Vivian Meazza wrote : As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -Fred I use LTProf here: http://www.lw-tech.com/ Small charge, but it seems to give some useful/meaningful results Vivian Are we sure that we are talking about the same topic and the same problem , as far i understand, = on one side, the cause is coming from compilation under an MS windows OS, = on the other side, there is problem within FG itself like described by AJ and Curt. AJ and I _think_ we are talking about the same problem. We might not be, although the description of the symptoms, which we have discussed many times, seems to be the same. The underlying cause might not be the same. It might be the code, the compiler, the OS. We don't know, which is why we need some more evidence. It might be different causes for AJ and for me. What we do know is that we had a much better solution a while back. Vivian So, i can try to explain why i don't notice any significant stutter with my configuration 32 bits one. May be, the power of the CPU AMD 3200 Athlon and GPU 7800 GS Nvidia Agp (running with Fedora Core 8) are enough for it and could explain that i don't have the problem. I only have lost FPS versus the performance of FG 1.0 for instance FG OSG = 70 fps FG 1.0.0 (with cloud and shadow) 80 fps Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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] FlightGear on 32 bits versus 64 bits system
James On 22 Sep 2008, at 22:25, Vivian Meazza wrote: AJ and I _think_ we are talking about the same problem. We might not be, although the description of the symptoms, which we have discussed many times, seems to be the same. The underlying cause might not be the same. It might be the code, the compiler, the OS. We don't know, which is why we need some more evidence. It might be different causes for AJ and for me. What we do know is that we had a much better solution a while back. Since this might be my fault, I'll say that as far as I know (of course I could be very, very wrong), none of my changes should have a noticeable performance impact (yet). For example, the marker-beacon instrument searches for nearby navaids of a certain type, and in the future I might change how the search is implemented, but right now all the old search methods are being used. Of course I could easily have made a mistake. The best solution is a binary search of CVS - rewind to a date which is 'known good' and the keep stepping forwards / back by half the time interval and checking- out / rebuilding / testing. Generally it will only take 4-8 iterations of this (tedious) process to narrow it down to a day, at which point we can see how I screwed up :) It would also be good to know if everyone sees this issue (or some variation), or only certain OS-es / people with slower machines / etc A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Vivian - 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] FlightGear on 32 bits versus 64 bits system
On 22 Sep 2008, at 23:05, Vivian Meazza wrote: A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. Well, being selfish, one around the start of August would rule my changes in or out - but if you're slogging through the binary search, I'll leave you to it. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK is hasn't been touched in a good long time. 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] FlightGear on 32 bits versus 64 bits system
On Mon, Sep 22, 2008 at 5:23 PM, James Turner wrote: On 22 Sep 2008, at 23:05, Vivian Meazza wrote: A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. Well, being selfish, one around the start of August would rule my changes in or out - but if you're slogging through the binary search, I'll leave you to it. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK is hasn't been touched in a good long time. Here's another idea to toss into the mix ... What aircraft is being flown in these tests? If hash.c looks like a hotspot, that could also be triggered by an aircraft that had a lot of new nasal code added. Or it could be newly added default system nasal code? I don't know how much of FlightGear functions anymore without nasal, but disabling the default nasal directory and picking an aircraft with little or no embedded nasal code might also be an interesting test. We could possibly have crossed a threshold in terms of the amount of nasal code used for some particular aircraft? Regards, 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] FlightGear on 32 bits versus 64 bits system
Fred Vivian Meazza wrote : My latest build with MSVC9 (32 bit) is suffering severe jitter, so much that it is unusable, as I mentioned earlier. I have profiled the code, but nothing obvious showed up yet. I'm continuing to look. I tried to compile FG with MSVC9 and it is far more slower than my 7.1 build. And the starting stage, loading scenery models, is very long even with that 7.1 build. Yes, although changing the optimisation options helps a bit with the frame rate, if not the loading. Profiling suggests this might be the long pole in the tent: simgear\source\simgear\nasal\hash.c With its children it is taking 6% of CPU time. The next highest, groundcache.cxx, takes only 0.4%. I'm not sure if that causes just slow running, or is a possible cause of jitter as well, or indeed if it is significant at all. I can go back to an earlier build dated 04/04/2008, which I happen to have kept, and it is reasonably smooth with good frame rates. I haven't finished profiling that yet. Vivian - 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
