inlining
Era Scarecrow
rtcvb32 at yahoo.com
Sat Jul 19 03:21:09 PDT 2008
> JAnderson wrote:
> > bobef wrote:
> >> This has probably been asked many times before. If
> someone knows of
> >> such discussion please paste me a link. Why not an
> 'inline' attribute?
> >> We all know that the compiler can be stupid some
> times, and even if it
> >> is not people may want to inline something that is
> normally not
> >> appropriate for inlining. Auto inlining is fine,
> but people should
> >> have control over such kind of things I believe.
> >>
> >> Regards, bobef
> >
> > May C++ compilers ignore the inline attribute because
> it has a better
> > handle on when to inline. There have been some
> studies (does anyone
> > have the links to these) where they've shown that
> most of the time the
> > compiler can make a more intelligent guess then the
> average engineer.
> >
> > But that's C++. D does this automatic
> virtual's thing so its difficult
> > to say whether the compiler can always make a good
> choice.
> >
> > -Joel
>
> I was working with MSVC++ the other day and found a couple
> of places
> where it wasn't inlining the code and was running slow.
> So I placed a
> few inlines around and *bam* that code started running
> faster. Then I
> profiled the code as a whole to see how much of an
> improvement I'd
> gained. However the game was actually running slower. It
> turned out
> that inlining had simply shifted the bottneck into memory
> and the
> program file size had got bigger, so the program cache was
> stalling all
> the time.
>
> I'm not against inlining, I just think that you have to
> be really
> careful when using it and understand its implications (ie
> use a
> profiler), otherwise you could be making things worse.
A good point.
Recently i've stepped away from C and trying to get away from ultra-optimizing code (which has made my best project look sloppy and i notice is ridden with extra code, in order to get gains that i am not sure i'm actually getting)
Could we, for instance use a profiler to comment and pull information from a running program, and than use that to get optimizations that it might otherwise have not noted?
I recall something like this, but i don't want to look it up. bare with me.
>(not exactly as before, but close)
> if (b)
> a = something;
> else
> a = somethingElse;
Then say b had a 90% chance of being positive or negative, the running profiler seeing that would then take the needed steps on a re-compiling stage using that profiling in order to optimize, without worrying about portability and readability problems?
We see the above code, the compiler does...
(if b is greater for being positive)
a=something;
if (!b)
a=somethingElse;
Course, unless there's something big or slow in the calls, or SomethingElse takes longer than something (besides a simple type), i don't think there's much of a speed gain. If for example the opposite was true..
(if b is greater for being positive)
char []buffer; //what for i'm not sure.
buffer=something;
if (!someflag)
buffer=new char[xxx];
Then the speed gains from not having to initialize the memory for some flag is still true, although it wouldn't be much speed gains honestly. hmm..
(Assembly would say, 1 compare, 1 jump, 1 assignment/call, regardless)
Oh well. Thoughts on an external profiler to assist with the compiler with optimization?
Era
More information about the Digitalmars-d
mailing list