On 02/13/2011 04:13 AM, so wrote:
On Sat, 12 Feb 2011 13:20:36 +0200, spir <denis.s...@gmail.com> wrote:
On 02/12/2011 12:15 PM, Jim wrote:
Sorry about that, but I think that is a closely related discussion. @inline
is certainly a verb -- even imperative mood, so not just asking for
information.
Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself.
Second, because it teaches me something. Third, because I can then possibly
decide to not factor out (may be wrong, but still, I can measure...).
Glasnost for compilers! ;-)
Denis
This is to all of you. Inlining is not a toy, knowing if a function is inlined
or not has no practical purposes in the sense you are asking, or any other for
that matter.
This is a low level optimization, again it is not a toy to play with, and D
being a system language (where function call is cheap) makes this even more
meaningless.
How many times do I need to repeat I do not want to force inlining? Or what
else are you talking about?
Instead, I want to /know/. Example use: ensure trivial externalisation dist
below will be properly inlined back by the compiler. I factorise out dist for
code clarity, but do not want this to cause stupid performance penalty. Cases:
* the compiler shut up --> ok
* the compiler says 'no' -- possibly 'because ...'
~ I can decide to unfactor out
~ I can measure, and realise cost of func call is nothing compared to
square root
~ I may learn something from additional info
~ I may realise the case is not as trivial as it seems
~ I may learn about highering chances of inlining
// billions of them
struct Point {
float x,y;
float d;
this (float x, float x) {
this.x = x;
this.y = y;
// inline or not inline?
this.d = dist(x,y);
pragma (inlineinfo) {
static float dist (int x, int y) {
return squareRoot(x*x + y*y);
}
}
}
Denis
--
_________________
vita es estrany
spir.wikidot.com
