December 30, 2011
On 12/30/2011 12:16 AM, Vladimir Panteleev wrote:
> I agree, but this wasn't as much about heuristics, but compiler capabilities
> (e.g. inlining assembler functions).

Adding a keyword won't fix the current problem that the compiler won't inline inline assembler functions. It's an orthogonal issue.

I know there are features on various C compilers to force inlining, I know there's a demand for them.

But I've also, over the years, spent thousands and thousands of hours optimizing the hell out of things, so I have some experience with it.

Once the compiler gets past a certain level of heuristic inlining decisions, forcing it to inline more is just chasing rainbows.

And if one really wants to force an inline, one can do things like the C memcpy using the preprocessor, or string mixins in D, or even cut&paste. If you need to do that in more than a couple places in the code, something else is wrong (that old saw about only a tiny percentage of the code being a bottleneck is true).

Also, if you are tweaking at such a level, every compiler is different enough that your tweaks are likely to be counterproductive on another compiler. Having a portable syntax for such tweaking is not going to help.
December 30, 2011
On 30/12/11 9:13 AM, Walter Bright wrote:
> And if one really wants to force an inline, one can do things like the C
> memcpy using the preprocessor, or string mixins in D, or even cut&paste.
> If you need to do that in more than a couple places in the code,
> something else is wrong (that old saw about only a tiny percentage of
> the code being a bottleneck is true).

When you are writing really performance sensitive code, that old adage is certainly *not* true.

It only happens in practice when you don't care that much about performance. When you really care, you've already optimised those hot spots, so what you end up with is a completely flat profile: no part of the program is the bottleneck, but the whole thing is.

At that point, you're likely suffering a death from a thousand cuts: no single part of your program is the bottleneck; your poor performance is just the sum total of a bunch of small performance penalties here and there.

A perfect example of this is vector operations. Games use vector operations all over the place, so their impact on performance is spread out over the entire program. You'll never see a dot product or vector addition routine at the top of a profile chart, but it will certainly affect performance!
December 30, 2011
> I completely agree that DMD's inliner is underpowered and needs improvement. I am less sure that this demonstrates that the language needs changes.
>
> Functions below a certain size should be inlined if possible. Those above that size do not benefit perceptibly from inlining. Where that certain size exactly is, who knows, but I doubt that functions near that size will benefit much from user intervention.

More specifically a distinction would be nice like gcc does:

"-finline-small-functions
Integrate functions into their callers when their body is smaller than expected function call code (so overall size of program gets smaller). The compiler heuristically decides which functions are simple enough to be worth integrating in this way.

Enabled at level -O2.

-finline-functions
Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth integrating in this way.

Enabled at level -O3."
December 30, 2011
On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
> Also, if you are tweaking at such a level, every compiler is different enough that your tweaks are likely to be counterproductive on another compiler. Having a portable syntax for such tweaking is not going to help.

Which is exactly why I think an inlining pragma/attribute should provide a guarantee, and not a hint. It's a web of assumptions/guarantees: asm blocks provide their guarantees, but using them introduces new assumptions, that e.g. force-inlining solidifies, etc.

Back to the macros vs.

> And if one really wants to force an inline, one can do things like the C memcpy using the preprocessor, or string mixins in D, or even cut&paste.

D has nothing from the above that's elegant and maintainable. Timon's solution comes close, but it uses a DSL to make up for what the language doesn't provide.

> If you need to do that in more than a couple places in the code, something else is wrong (that old saw about only a tiny percentage of the code being a bottleneck is true).

What about the context of creating an optimized library, as opposed to optimizing one application?
December 30, 2011
On Friday, 30 December 2011 at 12:00:07 UTC, Vladimir Panteleev wrote:
> Back to the macros vs.

Oops, didn't mean to send that. I was going to write that comparing C macros with __forceinline functions is much more of a level comparison.
December 30, 2011
On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
>> ** The X template
>
> Good work, but I'm not sure if inventing a DSL to make up for the
> problems in D string mixins that C macros don't have qualifies as "doing
> it right".

It certainly does. That is how all my code generation looks like. The fact that I am using string mixins to solve some problems shows that those are not 'problems in D string mixins'.
December 30, 2011
On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
> On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
>> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
>>> ** The X template
>>
>> Good work, but I'm not sure if inventing a DSL to make up for the
>> problems in D string mixins that C macros don't have qualifies as "doing
>> it right".
>
> It certainly does. That is how all my code generation looks like. The fact that I am using string mixins to solve some problems shows that those are not 'problems in D string mixins'.

Never mind. You're right. I hadn't thought of this before (using DSL nesting to avoid breaking token nesting); it's a nice idea. I think I'll steal this for my code :)
December 30, 2011
On Fri, 30 Dec 2011 14:00:06 +0200, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
>> Also, if you are tweaking at such a level, every compiler is different enough that your tweaks are likely to be counterproductive on another compiler. Having a portable syntax for such tweaking is not going to help.
>
> Which is exactly why I think an inlining pragma/attribute should provide a guarantee, and not a hint. It's a web of assumptions/guarantees: asm blocks provide their guarantees, but using them introduces new assumptions, that e.g. force-inlining solidifies, etc.

I agree @inline (which will probably be an extension) in D should mean force-inline.

Ignoring the impossible-to-inline cases (which in time should get better), adding @inline is a few minutes of editing.
It will just bypass the cost function and if it is not possible to inline, pop error. I don't have enough knowledge of DMD internals
so i am not sure if should go do it, or maybe i need to start somewhere...
December 30, 2011
On Fri, 30 Dec 2011 16:11:54 +0200, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
>> On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
>>> On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
>>>> ** The X template
>>>
>>> Good work, but I'm not sure if inventing a DSL to make up for the
>>> problems in D string mixins that C macros don't have qualifies as "doing
>>> it right".
>>
>> It certainly does. That is how all my code generation looks like. The fact that I am using string mixins to solve some problems shows that those are not 'problems in D string mixins'.
>
> Never mind. You're right. I hadn't thought of this before (using DSL nesting to avoid breaking token nesting); it's a nice idea. I think I'll steal this for my code :)

For me, mixin sounds much more intuitive than inline for what we are trying to achieve with force-inline.
If it was user friendly now that would be awesome.
December 30, 2011
On 12/30/2011 4:05 AM, Timon Gehr wrote:
> It certainly does. That is how all my code generation looks like. The fact that
> I am using string mixins to solve some problems shows that those are not
> 'problems in D string mixins'.

I your solution to parameterized strings is very nice. Can you write a brief article about it? This should be more widely known.