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
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
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.
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
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
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
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
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
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
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
10 matches
Mail list logo
