Based on several months of following this list I would guess that most of the CPU time in FGFS is spent in rendering the scenery. Just look at the recent reports of frame rate dropping with the addition of 3d clouds. Or perhaps people are limited by the graphics hardware? It sounds like the FDM and anything else can actually run acceptably on rather old hardware. Given that, and the trend toward dual core processors, it seems like splitting out the rendering into its own thread (if its not already) would make sense in the near future. Optimizing the rendering code would probably be a good thing even for us single-core folks, which is probably most everyone.
-Paul On Mon, 2005-07-04 at 19:05 +0100, Jim Campbell wrote: > Hi folks, > Hopefully I would like to start a discussion of Flightgear code > optimisation. > My first thoughts are that fgfs divides logically into a number of > sub-systems: > a) Flight Dynamics Modelling (FDM) > b) Exterior View > c) Cockpit input and output ie joystick controls,switches and displays. > d) Motion system > but for time being I am going to disregard the last!! > These sub-systems could be physically separated into "processes" > (programs, > threads - whatever you like to call them) and inter-linked with IPC eg > tcp/ip, > Unix sockets,etc. > This would enable: > 1) a critical block analysis (CBA) to be run on each sub-system to > identify the most > frequently used code which can then be optimised by any number of > techniques. > eg compiler optimisation,manual optimisation, re-writing in a more > "efficient > language" (without wishing to start a flame war, C++ and Object > Orientated > languages may be ideal for code development but I know of no object > orientated > hardware so they may not get the best out of the available > hardware.) > 2) running the different sub-systems on different inter-linked > computers and indeed > on different hardware (Intel is not famed for its floating point > arithmetic so FDM may > be better on PowerPC,UltraSPARC etc but there is a great range of > graphics hardware > which makes Linux/Intel flexible for "view" and "cockpit"). > 3) tuning the "frame" rate of individual sub-systems (the FDM itself > may benefit > from different and variable frame rate for the "lateral" and > "rotational" elements > of the aerodynamical derivative integrations) > > These are just my first thoughts without tracking through every line of > code as yet so > maybe some of this has already been done? I dont want to repeat things > that have already > been chewed over so any ideas would be welcome. > > cheers > Jim > > > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
