RE: [Flightgear-devel] inlining
Norman Vine writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
Ah, yes, but this is a tight loop. In my tests on props.hxx, the
inlined code came in the middle of a long code block. I didn't have
time to do a lot of rewriting, but even when I did something as simple
as
double x = 100 + jnk;
jnk = 1000 + test_junk(i);
double y = 50 / x;
jnk *= y;
the speed advantage of the inlined code was cut in half.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Norman Vine writes: However some code fragments run 100's or even 1000's of times per iteration and these fragments should be studied on an individual basis and not just automatically un-inlined because it is in 'vogue' :-) It's not a question of vogue. Currently, we start with an enormous amount of inlined code by default. I'm suggesting that we start with nothing (or almost nothing) inlined, then inline only what can be proven to help through profiling and timing tests -- uninlined until proven necessary, rather than inlined until proven unnecessary. This should make the executable smaller, compile times faster, headers more readable, and debuggers more useful, all as side-effects. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson writes:
Norman Vine writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
Ah, yes, but this is a tight loop.
Ah, good, you have a HINT at which inlines to leave alone :-
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson [EMAIL PROTECTED] said: I'm suggesting that we start with nothing (or almost nothing) inlined, then inline only what can be proven to help through profiling and timing tests -- uninlined until proven necessary, rather than inlined until proven unnecessary. This Sounds like a good plan. Not sure if we will see a big improvement on build times though. I would think a lot depends on how frequently a given inline is used. In any case, I've been slowly taking them out of the viewer code :::duck::: and haven't noticed any un-aided human detectible change. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
== cut ===
#include iostream
#include time.h
#define NUM_TESTS 1
double jnk = 0.0;
double make_junk( double a );
inline double test_junk( double a )
{
return (a-NUM_TESTS/2) 0 ? 0 : 1;
}
int main(int argc, char **argv)
{
int i;
int start;
start = clock();
for( i=0; iNUM_TESTS; i++)
{
jnk = make_junk(i);
}
cout elapsed clock() - start endl;
start = clock();
for( i=0; iNUM_TESTS; i++)
{
jnk = test_junk(i);
}
cout elapsed clock() - start endl;
}
double make_junk( double a )
{
return (a-NUM_TESTS/2) 0 ? 0 : 1;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Norman Vine wrote: Really ?? then try this both with and without optimization :-)) This program fits easily into the L1 cache. FlightGear does not. For small programs, total instructions executed is more important than code size. For most real programs on modern processors, just the opposite is true. Try writing a perl script that duplicates this code, say, 10k times (varying the symbol names each time) and iterates through each one of them. My guess is that you'll see the performance gain from inlining either disappear or turn into a loss. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Norman Vine wrote: However some code fragments run 100's or even 1000's of times per iteration and these fragments should be studied on an individual basis and not just automatically un-inlined because it is in 'vogue' :-) It's even more complicated than that. If you call a function thousands of times in succession, then it almost always pays to inline it. If you call it the same number of times, but interspersed evenly with the rest of the code, inlining is only going to thrash the cache and hurt performance. I have nothing against re-inlining stuff once it's profiled and shown to have a performance benefit, but inlining by default because it looks faster is self-defeating. FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, but the WeatherCM stuff and the Main directory aren't far behind. I mean, think about it: this compilation, if run on a VAX 11/780, would take 13 days! FlightGear is a big program, granted. But is it big enough to justify two weeks of machine time to compile? Sure, programmers are writing bigger software these days, but not *that* much bigger. FlightGear strikes me as about the same level of complexity as the whole of 4BSD Unix. Naively, I'd want it to build in about the same time. I'm certain 4BSD didn't take two weeks to build. :) [I'm assuming that a VAX performs about the same as a 1 MHz Athlon here, which is roughtly in the ballpark.] Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Andy Ross wrote: FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, Personally I only ever fly the default fdm so compiling the others is a waste of my time and resources. Maybe we should add an argument to configure to select which FDM(s) to compile: --with-fdm=all the default, compiles all fdm modules --with-fdm=yasim compiles only the specified fdm Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Andy Ross writes: FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. Understood but why didn't you just say this rather then talk about runtime performance ??? see below What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, but the WeatherCM stuff and the Main directory aren't far behind. WeatherCM can be bypassed with a configure switch I believe that JSBSim and UIUC and othe FDMs can be cut out of t he build by deleteing their entries from the FDM / Makefile.am and commenting out the appropriate lines in Main / fg_init.cxx :: void fgInitFDM() and removing their link lib directives from Main / Makefile.am You also have to #ifdef out UIUC aircraft_dir entries in fg_props.cxx main.cxx and fg_init.cxx This should speed up your YASim specific build time considerably FWIW Win2k 733 PIII 256 meg Cygwin without the above tricks #! /bin/sh # bootstrap.sh -- toplevel script for a fresh FlightGear Build make clean rm config.status rm config.cache CXXFLAGS=-O2 -W -Wall -march=i686 ./configure --with-network-olk=no --with-efence=no --with-logging=yes --with -jpeg-factory=yes make nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real19m42.347s user17m30.419s sys 2m18.101s So it looks like 20 minutes is a reality on somewhat 'modest' machines And Cygwin is a slow poke :-) FWIW_2 with above tricks for optimized YASIM build times ./configure (as above plus) --with-new-enviroment nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real11m39.212s user10m0.648s sys 1m40.002s Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real19m42.347s user17m30.419s sys 2m18.101s So it looks like 20 minutes is a reality on somewhat 'modest' machines And Cygwin is a slow poke :-) FWIW_2 with above tricks for optimized YASIM build times ./configure (as above plus) --with-new-enviroment nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real11m39.212s user10m0.648s sys 1m40.002s I build JSBSim standalone in 1:45 (that's minutes:seconds for all you smarties out there). Norman: did you leave out both JSBSIm and LaRCSim in that build? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
