On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
> Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful.

Ok, you are at this point, check assembly and find out that compiler ignores your recommendation with no error messages / explanations. Next step?

24-Feb-2014 00:46, Walter Bright пишет:
> On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
>> Part of the reason for forced inline is always inlining some core
>> primitives,
>> even in debug builds.
>
> Right - and if the compiler won't do it, how does the error message help?
>
That programmer is instantly aware that it can't be done due to some reason. Keep in mind that code changes with time and running profiler/disassembler on every tiny change to make sure the stuff is still inlined is highly counter-productive.

>  > I wouldn't not like to ever have to get down and look at ASM for
> every function just to make sure it was inlined.
>
> By the time you get to the point of checking on inlining, you're already
> looking at the assembler output, because the function is on the top of
> the profile of time wasters, and that's how you take it to the next
> level of performance.

A one-off activity. Now what guarantees you will have that it will keep getting inlined? Right, nothing.
>
> The trouble with an error message, is what (as the user) can you do
> about it?

Re-write till compiler loves it, that is what we do today anyway. Else we wouldn't mark it as force_inline in the first place.

With error - yo get a huge advantage - an _instant_ feedback that it doesn't do what you want it to do. Otherwise it gets the extra pleasure of running disassembler to pinpoint your favorite call sites or observing that your profiler shows the same awful stats.

-- 
Dmitry Olshansky

24-Feb-2014 00:40, Walter Bright пишет:
> On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
>> I think there should be some way to force the compiler to inline a
>> function. As
>> a bonus, the error message can tell the programmer why the function
>> could not be
>> inlined, allowing them to make the necessary adjustments.
>>
>> Different compilers will have different inlining capabilities, however
>> at the
>> point where programmers are forcing inlining on or off, they are already
>> micro-optimizing at a level which implies dependency on particular
>> compiler
>> implementations.
>
> I think it would be a porting nuisance to error out when the compiler
> can't inline. The user would then fix it by versioning out for that
> compiler, and then the user is back to the same state as it being a
> recommendation.

Porting across compilers you mean?
While porting making temporary changes is fine, like turning off force_inline where it doesn't work. Without this error you are facing a silent performance disaster you still need to figure out.

Fail fast for the win.

> Generally, when I optimize at that level, I have a window open on the
> assembler output of the compiler and I go back and forth on the source
> code until I get the shape of the assembler I need. Having compiler
> messages wouldn't be very helpful.

Will save you the trouble of looking at the assembly window to begin with. Because you known ahead of time you wouldn't see what you like.

-- 
Dmitry Olshansky

On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
> Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful.

Not everyone has time/knowledge for checking the ASM at every recompile. Personally I wouldn't be able to do something like this that much often, and yet I'd love to know that something is not working ASAP.

Code changes, and it changes a lot during development. Having a way to make sure that one or more functions stay inlined is handy to have. If such a pragma doesn't guarantee inlining, that means we will have no way to check it quickly. Sometimes fail fast is really the best choice.

On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
> On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
>> I'll add:
>>
>>     pragma(inline);
>
> That's just going to confuse people, because they'll think *this* forces inlining.

Perhaps, but there's precedent with how align works, and how default initialization of variables works.


> I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and
> pragma(default_inline) or something like that.

That makes documentation with a sorted list of pragmas impractical.

On Sunday, 23 February 2014 at 19:10:08 UTC, Namespace wrote:
> On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote:
>> Am 23.02.2014 13:07, schrieb Walter Bright:
>>> http://wiki.dlang.org/DIP56
>>>
>>> Manu has needed always inlining, and I've needed never inlining. This
>>> DIP proposes a simple solution.
>>
>> Why a pragma? Can't we use a UDA and give it some special meaning inside the compiler?
>
> +1
> I would also prefer an attribute which can be used as label.
>
> ----
> @inline(true):
> // ...
> @inline(false):
> // ...
> @inline(default):
> ----

I still prefer the attribute/UDA idea but in case of pragma:

pragma(inline, true);
pragma(inline, false);
pragma(inline, default);

?

On Sunday, 23 February 2014 at 21:38:46 UTC, Walter Bright wrote:
> On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
>> I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and
>> pragma(default_inline) or something like that.
>
> That makes documentation with a sorted list of pragmas impractical.

pragma(inline_always)
pragma(inline_never)
pragma(inline_default)

or

pragma(inline_force)
pragma(inline_prevent)
pragma(inline_default)

On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
> That programmer is instantly aware that it can't be done due to some reason.
> Keep in mind that code changes with time and running profiler/disassembler on
> every tiny change to make sure the stuff is still inlined is highly
> counter-productive.

I'm aware of that, but once you add the:

    version(BadCompiler) { } else pragma(inline, true);

things will never get better for BadCompiler. And besides, that line looks awful.


>> By the time you get to the point of checking on inlining, you're already
>> looking at the assembler output, because the function is on the top of
>> the profile of time wasters, and that's how you take it to the next
>> level of performance.
>
> A one-off activity. Now what guarantees you will have that it will keep getting
> inlined? Right, nothing.

You're always going to have that issue when optimizing at that level, and it will be for a large range of constructs. For example, you may need variable x to be enregistered. You may need some construct to be implemented as a ROL instruction. You may need a switch to be implemented as a binary search.


>> The trouble with an error message, is what (as the user) can you do
>> about it?
> Re-write till compiler loves it, that is what we do today anyway. Else we
> wouldn't mark it as force_inline in the first place.

In which case there will be two code paths selected with a version(BadCompiler). I have a hard time seeing the value in supporting both code paths - the programmer would just use the workaround code always.


> With error - yo get a huge advantage - an _instant_ feedback that it doesn't do
> what you want it to do. Otherwise it gets the extra pleasure of running
> disassembler to pinpoint your favorite call sites or observing that your
> profiler shows the same awful stats.

My point is you're going to have to look at the asm of the top functions on the profiler stats anyway, or you're wasting your time trying to optimize the code. (Speaking from considerable experience doing that.) There's a heluva lot more to optimizing effectively than inlining, and it takes some back-and-forth tweaking source code and looking at the assembler. I gave some examples of that above.

And yes, performance critical code often suffers from bit rot, and changes in the compiler, and needs to be re-tuned now and then.

I suspect if the compiler errors out on a failed inline, it'll be much less useful than one might think.

On 2/23/2014 1:32 PM, Francesco Cattoglio wrote:
> [...]

I addressed these three messages in another reply to Dmitry.

On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
> On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
>> That programmer is instantly aware that it can't be done due to some reason.
>> Keep in mind that code changes with time and running profiler/disassembler on
>> every tiny change to make sure the stuff is still inlined is highly
>> counter-productive.
>
> I'm aware of that, but once you add the:
>
>     version(BadCompiler) { } else pragma(inline, true);

Once one resorts to force_inline and similar micro-optimisations he usually sticks to single "good" compiler as code gen needs to be re-profiled for each compiler anyway.