inlining...
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Thu Mar 20 01:35:21 PDT 2014
On Thursday, 20 March 2014 at 02:08:16 UTC, Manu wrote:
> The problem is upside down. If you want to inline multiple
> levels, you
> start from the leaves and move downwards, not from the root
> moving upwards
Yes, that is true in cases where leaves are frequently visited.
Good point. I am most interested in full inlining, but the
heuristics should probably start with the leaves for people not
interested in that. Agree.
Anyway, in the case of ray tracing (or any search structure) I
could see the value of having the opposite in combination with
CTFE/partial evaluation.
Example: Define a static scene (of objects) and let the compiler
turn it into "a state machine" of code.
Another example: Define an array of data, use partial evaluation
to turn it into a binary tree, then turn the binary tree into
code.
> Inlining should be strictly deliberate, there's nothing to say
> that every
> function called in a tree should be inlined. There's a high
> probability
> there's one/some that shouldn't be among a few that should.
In the case of a long running loop it does not really matter.
What it does get you is a chance to use generic code (or
libraries) and then do a first-resort optimization. I basically
see it as a time-saving feature (programmers time). A tool for
cutting development costs.
> Remember too, that call-site inlining isn't the only method,
> there would
> also be always-inline...
Yes, that is the first. I have in another thread some time ago
suggested a solution that use weighted inlining to aid compiler
heuristics:
http://forum.dlang.org/thread/szjkyfpnachnnyknnfwp@forum.dlang.org#post-szjkyfpnachnnyknnfwp:40forum.dlang.org
As you can see I also suggested call-site inlining, so I am fully
behind you in this. :-) Lack of inlining and GC are my main
objections to D.
> I think always-inline is what you want for some
> decidedly trivial functions (although these will probably be
> heuristically
> inlined anyway), not call-site inlining.
I agree. Compiler heuristics can change. It is desirable to be
able to express intent no matter what the current heuristics are.
> I just don't see how recursive
> call-site inlining is appropriate, considering that call trees
> are often
> complex, subject to change, and may even call functions that
> you don't have
> source for.
You should not use it blindly.
> You can cascade the mixin keyword if you want to, that's very
> simple.
Not if you build the innerloop using generic components. I want
this
inline_everything while(conditon){
statement;
statement;
}
> I'd be highly surprised if you ever encountered a call tree
> where
> you wanted to inline everything (and the optimiser didn't do it
> for you).
Not if you move to high-level programming using prewritten code
and only go low level after profiling.
> As soon as you encounter a single function in the tree that
> shouldn't be
> inlined, then you'll be forced to do it one level at a time
> anyway.
But then you have to change the libraries you are using!?
Nothing prevents you to introduce exceptions as an extension
though. I want inline(0.5) as default, but also be able to write
inline(1) for inline always and inline(0) for inline never.
func1(){} // implies inline(0.5) weighting
inline func2(){} // same as inline(1) weighting, inline always
inline(0.75) fun31(){} // increase the heuristics weighting
inline(0) func4(){} // never-ever inline
Ola.
More information about the Digitalmars-d
mailing list