On Monday, 24 February 2014 at 00:33:09 UTC, Walter Bright wrote:
> I suspect that elevating one particular optimization hint to being an absolute command may not turn out well. Inlining already has performance issues, as it may increase the size of an inner loop beyond what will fit in the cache, for just one unexpected result. For another it may mess up the register allocation of the caller. "Inlining makes it faster" is not always true. Do you really want to weld this in as an absolute requirement in the language?

The fact that original C "inline" was designed in same "permissive" way and is almost unused in practice (as opposed to compiler-specific force_inline attributes) does say something.

It is not feature that should be design for mass usage.

Le 23/02/2014 13:07, Walter Bright a écrit :
> http://wiki.dlang.org/DIP56
>
> Manu has needed always inlining, and I've needed never inlining. This
> DIP proposes a simple solution.

I saw many times C++ developers works on applications doesn't need such level optimization puts inline keyword or implementation in headers files without doing any performance analysis!!! And as I saw they don't know X86 neither,...
For those doesn't have necessary knowledge it's just counter productive and increase the compilation times without evidence of the interest.

So my point is this kind of feature have to be hidden from newbies (like me) and other developers who are zealous.

On 2/23/2014 4:21 PM, Tove wrote:
> Inspecting asm output doesn't scale well to huge projects. Imagine simply
> updating the existing codebase to use a new compiler version.

Again, this is treating 'inline' as being the only optimization that matters? It's not even the most important - that would likely be register allocation.

At some point, you're going to need to trust the compiler.


> You are right in that there is nothing special about inlining, but I'd rather
> add warnings for all other failed optimisation opportunities than not to warn
> about failed inlining. RVCT for instance has --diag_warning=optimizations, which
> gives many helpful hints, such as alias issues: please add "restrict", or
> possible alignment issues etc.

There are *thousands* of optimization patterns. Logging which ones were applied to each expression node would be utterly useless to anyone but a compiler writer. (You can turn this on in debug builds of the compiler and see for yourself.)

The most effective log is to look at the asm output. There isn't a substitute. I know that doesn't scale, going back to my point that at some point you're going to have to spot check here and there and otherwise trust the compiler.

I know that most programmers don't want to look at the asm output. Whether an error for failed inlining is or is not issued won't change the need to have a look now and then, if you want your code to be the fastest it can be.

BTW, although the DIP says the compiler can ignore it, in practice there aren't going to be perverse compilers. Compiler writers want their compilers to be useful, and don't go out of their way to sneakily interpret the spec to do as bad a job as possible. Conversely, the history of programmer-supplied optimizer edicts (see 'register') is not a very good one, as programmers are often not terribly cognizant of the tradeoffs and tend to use overly simplistic rules when applying these edicts. As optimizers improve, they shouldn't be impeded by well-intentioned but wrong optimization edicts.

(An early version of my C compiler had a long list of various optimization strategies that could be turned on/off. Never once was any appropriate use made of these. It's why dmd has evolved to simply have -O. -inline is a separate switch for reasons of symbolic debuggability.)

>
> The fact that original C "inline" was designed in same "permissive" way and is almost unused in practice (as opposed to compiler-specific force_inline attributes) does say something.
>

Do you mind to back up your "fact" with some numbers? Afaict 'inline' is more common than __attribute__((forceinline)). (Well ok for C code #define is even more common, but most C code is stuck in the 70ies anyway so that doesn't mean anything.)

On 2/23/14, 4:07 AM, Walter Bright wrote:
> http://wiki.dlang.org/DIP56
>
> Manu has needed always inlining, and I've needed never inlining. This
> DIP proposes a simple solution.

This makes inlining dependent on previously-seen code. Would that make parallel compilation more difficult?

I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions.


Andrei

On Monday, 24 February 2014 at 01:12:56 UTC, Andrei Alexandrescu wrote:
> This makes inlining dependent on previously-seen code. Would that make parallel compilation more difficult?
>
> I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions.
>
>
> Andrei

That seems to be how Rust does it, but I'm not really clear how attributes work in Rust.

http://static.rust-lang.org/doc/master/rust.html#inline-attributes

On 2/23/14, 5:05 PM, Walter Bright wrote:
> On 2/23/2014 4:21 PM, Tove wrote:
>> Inspecting asm output doesn't scale well to huge projects. Imagine simply
>> updating the existing codebase to use a new compiler version.
>
> Again, this is treating 'inline' as being the only optimization that
> matters? It's not even the most important - that would likely be
> register allocation.
>
> At some point, you're going to need to trust the compiler.

At this point, you're starting to argue that the entire DIP isn't relevant.  I agree with the majority that if you're going to have the directive, then it needs to be enforcement, not suggestion.

On 24/02/14 06:12, Walter Bright wrote:
> On 2/23/2014 1:41 PM, Namespace wrote:
>> pragma(inline, true);
>> pragma(inline, false);
>> pragma(inline, default);
>
> 'default' being a keyword makes for an ugly special case in how pragmas
> are parsed.
>

Aren't true and false keywords as well?

Andrei Alexandrescu:

> I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions.

Seems good. And what do you think the D compiler should do when you use @forceinline and it can't inline?

Bye,
bearophile

On 2/23/2014 5:45 PM, Brad Roberts wrote:
> At this point, you're starting to argue that the entire DIP isn't relevant.  I
> agree with the majority that if you're going to have the directive, then it
> needs to be enforcement, not suggestion.

1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code.

2. Making it a hard requirement then means the user will have to put versioning in it. It becomes inherently non-portable. There is no way to predict what some other version of some other compiler on some other system will do.

3. In the end, the compiler should make the decision. Inlining does not always result in faster code, as I pointed out in another post.

4. I don't see that users really are asking for inlining or not. They are asking for the fastest code. As such, providing hints about usage frequencies are entirely appropriate. Micromanaging the method used is not so appropriate. After all, the reason one uses a compiler in the first place rather than assembler is to not micromanage the actual instructions.


Perhaps the lesson is the word 'inline' carries certain expectations with it, and the feature would be better positioned as something like:

    pragma(usage, often);
    pragma(usage, rare);