Re: [Flightgear-devel] Compiler Warnings
On 26 Sep 2010, at 22:09, ThorstenB wrote: Hi, there is a forum topic discussing compiler optimization to improve frame rate ( http://www.flightgear.org/forums/viewtopic.php?f=45p=96830 ). I have also tried this (and successfully improved mine... :-) ). However, I also compiled with -Wall and this shows several issues with the FlightGear sources. Simgear is really clean though (no warnings with g++ 4.4, *clapclap*). I'm seeing 55 warnings with FlightGear: mainly (potential) usage of uninitialized variables and violations of strict aliasing. The latter easily results in broken code when optimizing with -O2 or above (oh no, -O2 is the FlightGear default!). Well, and there is another 54 warnings in the AI module, but only since the member variables aren't initialized in the sequence of their declaration (very easily fixed). In general, fixing warnings and switching on -Wall would get my vote; various people have done work on this over the past few years - Torsten Dryer and myself recently, but several others too. I'm not sure we can achieve the equivalent for all compilers, but requiring -Wall and possibly -Werror (optionally!) for GCC 4.4 would be nice. Patches welcome :) Regarding the compile flags, I'd prefer to use the default system CXXFLAGS by default, but provide a --aggressive or --optimised configure option that does this. Apple strongly recommend -Os over -O2 or -O3, as the default for production code, with -O2 or -O3 enabled on a file-by-file or module-by-module basis. This is really Apple saying they think i-cache coherency is a bigger win than massive loop unrolling, inlining and the like. They also recommend using profiling to identify the actual hot functions, since I'd guess the hot functions in the FlightGear frame loop are in OSG, not FlightGear itself. Even the FDMs aren't that hot, comparatively. If anyone could compare -Os with -O3 (with march=native and SSE enabled), and post the frame-rate difference, I'd be interested. (The comments above do date from the PPC days, some of which were i-cache starved) The SSE math flags are a no-brainer where supported - the -march-native and -sse flags are all Apple defaults in Xcode. James -- 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] Compiler Warnings
Hi all, As a general head-up. I'm trying to fix a couple of these warnings in the AI code right now. Most of it is just boring stuff. Ideal to fill a couple of hours on a rainy monday afternoon. Cheers, Durk On Mon, Sep 27, 2010 at 9:47 AM, James Turner zakal...@mac.com wrote: On 26 Sep 2010, at 22:09, ThorstenB wrote: Hi, there is a forum topic discussing compiler optimization to improve frame rate ( http://www.flightgear.org/forums/viewtopic.php?f=45p=96830 ). I have also tried this (and successfully improved mine... :-) ). However, I also compiled with -Wall and this shows several issues with the FlightGear sources. Simgear is really clean though (no warnings with g++ 4.4, *clapclap*). I'm seeing 55 warnings with FlightGear: mainly (potential) usage of uninitialized variables and violations of strict aliasing. The latter easily results in broken code when optimizing with -O2 or above (oh no, -O2 is the FlightGear default!). Well, and there is another 54 warnings in the AI module, but only since the member variables aren't initialized in the sequence of their declaration (very easily fixed). In general, fixing warnings and switching on -Wall would get my vote; various people have done work on this over the past few years - Torsten Dryer and myself recently, but several others too. I'm not sure we can achieve the equivalent for all compilers, but requiring -Wall and possibly -Werror (optionally!) for GCC 4.4 would be nice. Patches welcome :) Regarding the compile flags, I'd prefer to use the default system CXXFLAGS by default, but provide a --aggressive or --optimised configure option that does this. Apple strongly recommend -Os over -O2 or -O3, as the default for production code, with -O2 or -O3 enabled on a file-by-file or module-by-module basis. This is really Apple saying they think i-cache coherency is a bigger win than massive loop unrolling, inlining and the like. They also recommend using profiling to identify the actual hot functions, since I'd guess the hot functions in the FlightGear frame loop are in OSG, not FlightGear itself. Even the FDMs aren't that hot, comparatively. If anyone could compare -Os with -O3 (with march=native and SSE enabled), and post the frame-rate difference, I'd be interested. (The comments above do date from the PPC days, some of which were i-cache starved) The SSE math flags are a no-brainer where supported - the -march-native and -sse flags are all Apple defaults in Xcode. James -- 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 -- 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] Compiler Warnings
For your information, I just committed a bunch of fixes so that the AIModels subdirectory now compiles without warnings using -Wall, using gcc 4.3.2 Cheers, Durk -- 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] Compiler Warnings
James Turner wrote: The SSE math flags are a no-brainer where supported - the -march-native and -sse flags are all Apple defaults in Xcode. BTW, as far as I remember the -sse and -sse2 are on by default for GCC on AMD64 (alias x86_64). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Compiler Warnings
On 27 Sep 2010, at 17:48, Martin Spott wrote: The SSE math flags are a no-brainer where supported - the -march-native and -sse flags are all Apple defaults in Xcode. BTW, as far as I remember the -sse and -sse2 are on by default for GCC on AMD64 (alias x86_64). It would be good if someone who found -O3 -march=native -sse -sse3 made a difference, ciuld verify this, i.e try without the explicit SSE flags, and see if the performance is the same. march=native might be they key thing here, if the default arch is i386 or i686, and hence prohibiting SSE from being considered. James -- 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] Compiler Warnings
On 2010-09-27, at 17:25, James Turner wrote: The SSE math flags are a no-brainer where supported - the -march-native and -sse flags are all Apple defaults in Xcode. BTW, as far as I remember the -sse and -sse2 are on by default for GCC on AMD64 (alias x86_64). It would be good if someone who found -O3 -march=native -sse -sse3 made a difference, ciuld verify this, i.e try without the explicit SSE flags, and see if the performance is the same. march=native might be they key thing here, if the default arch is i386 or i686, and hence prohibiting SSE from being considered. I just did a similar comparison this weekend (-march=native vs ... -sse -sse3 vs -mfpmath=sse on AMD64). But I tricked myself by forgetting to disable real weather fetch (stupid!). So I mainly compared the effect of this weekends' changing weather (cloud) scenarios... :-( Better do not repeat my mistake... :-) cheers, Thorsten -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot key bindings and the problem of backspace
Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- 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] Autopilot key bindings and the problem of backspace
On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- 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 -- Best Regards Willie Fleming 0141 637 6443 07799 67 88 15 a href=http://www.uwdcvideos.co.uk/index.taf?exref=174007v=1; target=_blank img src=http://www.uwdcvideos.co.uk/images/b1.gif; border= 0 width=468 height=60/a -- 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] Autopilot key bindings and the problem of backspace
Willie wrote: On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart I use Ctrl W and Ctrl P a great deal without looking at the gui, and would hate to lose them. Ctrl H would be useful, but it doesn't work like the previous 2, in that it doesn't hold the current heading. ISTR that it did at one point, but would not swear to it. Similarly, Ctrl S. I think these key bindings are traditional, in that the older flight sims used them. I would expect that many of the older hands would expect them to be as they are: I wonder if a change is _really_ needed? That said I have no particular preference for either solution 2 or 3 above. Vivian -- 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] Autopilot key bindings and the problem of backspace
On 27/09/10 22:11, willie wrote: btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? It works OK - it just sends the help message to the console, which is not much use in full-screen mode. Willie -- 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] Compiler Warnings = Merge Request
Hi, I fixed the strict-aliasing issues reported by GCC 4.4.1. Affects the generic.cxx and multiplaymgr.cxx modules. I created a merge request (let me know if you preferred patches): http://gitorious.org/fg/flightgear/merge_requests/7 cheers, Thorsten -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiler Warnings = Merge Request
On Tue, Sep 28, 2010 at 12:21 AM, ThorstenB bre...@gmail.com wrote: Hi, I fixed the strict-aliasing issues reported by GCC 4.4.1. Affects the generic.cxx and multiplaymgr.cxx modules. Unfortunately the trick with the union in multiplaymgr.cxx is not standard C, as far as I know. -- Csaba/Jester -- 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
