Julian Foad writes:
> I experimented with the effect of inlining on code size and compile
> times (but not run-time performance) on the src/FDM/JSBSim tree
> within FlightGear CVS as of about a week ago. I did this by
> supplying different compiler options with "make
> CFLAGS=... CXXFLAGS=.
Andy Ross wrote:
>
> Julian Foad wrote:
> > Code size:
> >secondsbytes options
> > Smallest:203 761360 -g -O1 -finline-limit-6 -finline-functions
> > Smallest O2: 233 767064 -g -O2 -finline-limit-6 -finline-functions
> > Default: 3881328284 -g -O2
> >
Julian Foad wrote:
> Code size:
>secondsbytes options
> Smallest:203 761360 -g -O1 -finline-limit-6 -finline-functions
> Smallest O2: 233 767064 -g -O2 -finline-limit-6 -finline-functions
> Default: 3881328284 -g -O2
> Largest: 3881328284 -g -
Andy Ross wrote:
>
> How about compile time?
I experimented with the effect of inlining on code size and compile times (but not
run-time performance) on the src/FDM/JSBSim tree within FlightGear CVS as of about a
week ago. I did this by supplying different compiler options with "make CFLAGS=.
> > Tony -
> >
> > Did you come up with any recommendations on what we should do
> with inlining
> > given your test results?
>
> Not really, I was just after trying to find out how much inlining is
> worth to us.
>
> It did look like we might benefit from un-inlining some of the tied
> methods, t
On Sat, 2002-03-23 at 13:43, Jon Berndt wrote:
> > I have to back off of the 15 minutes I quoted earlier -- that was
> > running over NFS, and with other stuff hammering on the same drive.
> > Still, it's quite clear that inlining is our problem here. The
> > difference between inlined-but-optimi
On Sat, 2002-03-23 at 13:37, Andy Ross wrote:
> Tony Peden wrote:
> > Jon S. Berndt wrote:
> > > With optimization turned on as described above I got a build time (total
> > > rebuild) of 3 minutes 30 seconds. So, in my case it didn't quite double.
> > >
> > > Thanks for the heads-up.
> > >
> I have to back off of the 15 minutes I quoted earlier -- that was
> running over NFS, and with other stuff hammering on the same drive.
> Still, it's quite clear that inlining is our problem here. The
> difference between inlined-but-optimized code and completely
> unoptimized code is only 13%,
Tony Peden wrote:
> Jon S. Berndt wrote:
> > With optimization turned on as described above I got a build time (total
> > rebuild) of 3 minutes 30 seconds. So, in my case it didn't quite double.
> >
> > Thanks for the heads-up.
> >
> > Tony, what do you see on your machine?
>
>
> [tony@r
On Sat, 2002-03-23 at 12:17, Jon Berndt wrote:
> > Try the version in FlightGear, not the standalone one. I think my
> > theory about you guys having optimization disabled is sounding more
> > correct. The one that gets built out of FlightGear's CVS uses the
> > standard -O2 flag, and is dog slo
> Try the version in FlightGear, not the standalone one. I think my
> theory about you guys having optimization disabled is sounding more
> correct. The one that gets built out of FlightGear's CVS uses the
> standard -O2 flag, and is dog slow.
OK, I ran a test using the -O2 setting just to see
Jon S. Berndt wrote:
> Andy Ross wrote:
> > Is it possible that the JSBSim from CVS builds without
> > optimization and that therefore the core developers aren't aware
> > how slow things are for those building from the FlightGear tree?
>
> This is really hard to believe. On my machine (whic
> How about compile time? I've been meaning to bug you about this. :)
>
> The new version of FGState.cpp, as checked in a few days ago, takes
> five (!) minutes to build on my machine. Yikes. The whole of JSBSim
> is running well over 15 minutes of compile time now. Turning off
> optimization,
Tony Peden wrote:
> I've done some experiments with inlining this morning. First I
> blindly removed all of the inline keywords from all JSBSim headers,
> then compiled with -O2 -fno-default-inline. For the c172 in a 300 sim
> second run of steady-level flight following a trim, this required
Tony Peden writes:
> This seems very attractive, but it also seems to break the OO. My
> personal feeling is that it would be better to chase JSBSim design
> improvements and live with the cost of tieing to object methods.
Sounds fair -- that's the kind of approach I've learned to appreciat
On Sat, 2002-03-23 at 07:02, David Megginson wrote:
> Tony Peden writes:
>
> > > What property-related methods show up
> > > near the top in the profiling?
> >
> > SGPropertyNode::getDoubleValue()
> >
> > This makes perfect sense, because it's called in place of
> > FGState::GetParameter
Tony Peden writes:
> > What property-related methods show up
> > near the top in the profiling?
>
> SGPropertyNode::getDoubleValue()
>
> This makes perfect sense, because it's called in place of
> FGState::GetParameter which used to be the big hitter.
I had been thinking about eliminati
On Sat, 2002-03-23 at 06:26, David Megginson wrote:
> Tony Peden writes:
>
> > Also, I was able to better quantify the performance change due to
> > incorporating the properties code. Prior to this, I had done speed
> > comparisons with the profiling code compiled in, but now I'm not so sure
> The other possibility is that the new multi-FDM stubs are slowing
> things down, but that seems unlikely.
There's very little there that's being used - and nothing being used unless
it's defined in the config file as a multi-body sim.
Jon
___
Fligh
Tony Peden writes:
> Also, I was able to better quantify the performance change due to
> incorporating the properties code. Prior to this, I had done speed
> comparisons with the profiling code compiled in, but now I'm not so sure
> that's fair. So:
> pre-props: 1.3 seconds average
> post
20 matches
Mail list logo
