www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - force inline/not-inline

reply Manu <turkeyman gmail.com> writes:
I just started writing an emulator in D for some fun; I needed an
application to case-study aggressive performance characteristics in
hot-loop situations.
I know this has come up time and time again, but I just want to put it out
there again... if I were shipping this product, I would NEED forceinline +
force-not-inline.

I know D likes to try and intelligently inline code, but in these very high
performance cases, I know what's best for my code, and I have also shipped
this product commercially before. I know exactly what was required of it
from months of meticulous performance profiling, and I can see immediately
that D is not making the right choices. Programmers need to be able to
explicitly control to inline-ing in many cases.

Cross module inline-ing is a really big problem. What is the plan here? Is
there a solution in the foreseeable future? What about libs?
Mar 17 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 17-03-2012 23:53, Manu wrote:

 I just started writing an emulator in D for some fun; I needed an
 application to case-study aggressive performance characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want to put it
 out there again... if I were shipping this product, I would NEED
 forceinline + force-not-inline.

 I know D likes to try and intelligently inline code, but in these very
 high performance cases, I know what's best for my code, and I have also
 shipped this product commercially before. I know exactly what was
 required of it from months of meticulous performance profiling, and I
 can see immediately that D is not making the right choices. Programmers
 need to be able to explicitly control to inline-ing in many cases.


Amen.


 Cross module inline-ing is a really big problem. What is the plan here?
 Is there a solution in the foreseeable future? What about libs?


-- 
- Alex
Mar 17 2012
prev sibling next sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 17.03.2012 23:53, schrieb Manu:

 I just started writing an emulator in D for some fun; I needed an
 application to case-study aggressive performance characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want to put it
 out there again... if I were shipping this product, I would NEED
 forceinline + force-not-inline.

 I know D likes to try and intelligently inline code, but in these very
 high performance cases, I know what's best for my code, and I have also
 shipped this product commercially before. I know exactly what was
 required of it from months of meticulous performance profiling, and I
 can see immediately that D is not making the right choices. Programmers
 need to be able to explicitly control to inline-ing in many cases.

 Cross module inline-ing is a really big problem. What is the plan here?
 Is there a solution in the foreseeable future? What about libs?


+1

Currently I use string mixins to force inlining - but that's uggly
Mar 18 2012
parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2012 10:56, Adrian <adrian.remove-nospam veith-system.de> wrote:


 +1

 Currently I use string mixins to force inlining - but that's uggly


Yeah, that's not an acceptable workaround. I couldn't write
commercial/large-team code that way.
Mar 18 2012
parent "Temtaime" <temtaime gmail.com> writes:
Bump.
Will forceinline be introduced?
Aug 24 2013
prev sibling next sibling parent reply "jerro" <a a.com> writes:
On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:

 I just started writing an emulator in D for some fun; I needed 
 an
 application to case-study aggressive performance 
 characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want to 
 put it out
 there again... if I were shipping this product, I would NEED 
 forceinline +
 force-not-inline.


You could use GDC and  attribute("forceinline") and
 attribute("noinline"). But I agree it would be nice to have
something like that as a part of the language.
Aug 24 2013
parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Saturday, 24 August 2013 at 19:13:49 UTC, jerro wrote:

 On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:

 I just started writing an emulator in D for some fun; I needed 
 an
 application to case-study aggressive performance 
 characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want 
 to put it out
 there again... if I were shipping this product, I would NEED 
 forceinline +
 force-not-inline.


 You could use GDC and  attribute("forceinline") and
  attribute("noinline"). But I agree it would be nice to have
 something like that as a part of the language.


Don't mean to resurrect an old thread but was working n a project 
to replace a few C programs today, that are time-sensitive and 
process fairly large batches of files, for live-use.

Was looking for a way to inline a few function calls that could 
shave a few seconds off my run time today, ended up using GDC 
attribute flags but was hoping the language had this feature.

Though I understand it intelligently decides, sometimes it 
doesn't do so well.

Case in point might be a call that at first glance doesn't get 
called often, but when in production, gets called thousands of 
times. That could be massive savings if it were able to force 
inline.

-Brandon
Jul 26 2015
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 26 July 2015 at 21:58:02 UTC, Brandon Ragland wrote:

 On Saturday, 24 August 2013 at 19:13:49 UTC, jerro wrote:

 [...]


 Don't mean to resurrect an old thread but was working n a 
 project to replace a few C programs today, that are 
 time-sensitive and process fairly large batches of files, for 
 live-use.

 Was looking for a way to inline a few function calls that could 
 shave a few seconds off my run time today, ended up using GDC 
 attribute flags but was hoping the language had this feature.

 Though I understand it intelligently decides, sometimes it 
 doesn't do so well.

 Case in point might be a call that at first glance doesn't get 
 called often, but when in production, gets called thousands of 
 times. That could be massive savings if it were able to force 
 inline.

 -Brandon


It looks like support is being considered:

http://dlang.org/pragma.html#inline
Jul 26 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 26 July 2015 at 22:59:49 UTC, Gary Willoughby wrote:

 It looks like support is being considered:

 http://dlang.org/pragma.html#inline


Yeah. IIRC, there was a big discussion a few months back on how 
pragma(inline) worked vs how it should work. In particular, I 
think that there was a big dispute over whether pragma(inline, 
true) should force inlining outright or make it so that it gave 
you an error if it wasn't inlined. I'd have to go find that 
discussion and dig through it though to know for sure what was 
being discussed exactly. I paid some attention to it, but not a 
lot.

- Jonathan M Davis
Jul 26 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 27 July 2015 at 02:19:28 UTC, Jonathan M Davis wrote:

 On Sunday, 26 July 2015 at 22:59:49 UTC, Gary Willoughby wrote:

 It looks like support is being considered:

 http://dlang.org/pragma.html#inline


 Yeah. IIRC, there was a big discussion a few months back on how 
 pragma(inline) worked vs how it should work. In particular, I 
 think that there was a big dispute over whether pragma(inline, 
 true) should force inlining outright or make it so that it gave 
 you an error if it wasn't inlined. I'd have to go find that 
 discussion and dig through it though to know for sure what was 
 being discussed exactly. I paid some attention to it, but not a 
 lot.


The result was that the pragma _forces_ inlining. If the compiler 
cannot inline it for whatever reason, it prints an error and 
exits. This is mostly to accommodate DMD, which has some 
restrictions about which functions can be inlined.
Jul 27 2015
parent reply "tcak" <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Monday, 27 July 2015 at 08:52:02 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 02:19:28 UTC, Jonathan M Davis wrote:

 [...]


 The result was that the pragma _forces_ inlining. If the 
 compiler cannot inline it for whatever reason, it prints an 
 error and exits. This is mostly to accommodate DMD, which has 
 some restrictions about which functions can be inlined.


Why not like pragma(inline, [try | force | no]) ?
Jul 27 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"tcak"  wrote in message news:psflpqqpsukpfgpzhngn forum.dlang.org... 


 Why not like pragma(inline, [try | force | no]) ?


Walter liked the boolean version, which is certainly better than nothing.
Jul 27 2015
parent reply "Adrian Matoga" <epi atari8.info> writes:
On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:

 "tcak"  wrote in message 
 news:psflpqqpsukpfgpzhngn forum.dlang.org...


 Why not like pragma(inline, [try | force | no]) ?


 Walter liked the boolean version, which is certainly better 
 than nothing.


I regret I missed this pull request and the chance to vote for 
"always"/"never" proposed by yebblies, which hit the right 
neurons in reader's brain instantly, unlike the generic 
true/false.
Jul 28 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:

 On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:

 "tcak"  wrote in message 
 news:psflpqqpsukpfgpzhngn forum.dlang.org...


 Why not like pragma(inline, [try | force | no]) ?


 Walter liked the boolean version, which is certainly better 
 than nothing.


 I regret I missed this pull request and the chance to vote for 
 "always"/"never" proposed by yebblies, which hit the right 
 neurons in reader's brain instantly, unlike the generic 
 true/false.


Someone made this exact suggestion in the PR, but as happens with 
most sensible suggestions, it was shot down.
Jul 28 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 28 July 2015 at 13:30:52 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:

 On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:

 "tcak"  wrote in message 
 news:psflpqqpsukpfgpzhngn forum.dlang.org...


 Why not like pragma(inline, [try | force | no]) ?


 Walter liked the boolean version, which is certainly better 
 than nothing.


 I regret I missed this pull request and the chance to vote for 
 "always"/"never" proposed by yebblies, which hit the right 
 neurons in reader's brain instantly, unlike the generic 
 true/false.


 Someone made this exact suggestion in the PR, but as happens 
 with most sensible suggestions, it was shot down.


I feel like that is becoming a trend for D, lately it feels like 
the only things that end up making its way into the language are 
dirty hacks.
Jul 28 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/28/15 9:30 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Tuesday, 28 July 2015 at 12:46:25 UTC, Adrian Matoga wrote:

 On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote:

 "tcak"  wrote in message news:psflpqqpsukpfgpzhngn forum.dlang.org...


 Why not like pragma(inline, [try | force | no]) ?


 Walter liked the boolean version, which is certainly better than
 nothing.


 I regret I missed this pull request and the chance to vote for
 "always"/"never" proposed by yebblies, which hit the right neurons in
 reader's brain instantly, unlike the generic true/false.


 Someone made this exact suggestion in the PR, but as happens with most
 sensible suggestions, it was shot down.


the only thing I can thing of is that true/false are (or have the 
potential to be in this context) expressions, which means one could use 
compile-time logic to specify inlining. The same wouldn't be true of 
arbitrary identifiers.

-Steve
Jul 28 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 28 July 2015 at 15:15:58 UTC, Steven Schveighoffer 
wrote:

 the only thing I can thing of is that true/false are (or have 
 the potential to be in this context) expressions, which means 
 one could use compile-time logic to specify inlining. The same 
 wouldn't be true of arbitrary identifiers.


Which is likely why boolean values were chosen. It's the same for 
why if we ever do end up with being able to negate attributes, 
it's almost certainly going to be something like final(false) 
rather than !final. It's far more flexible in generic code.

Now, in the case of inlining, I don't know how much it actually 
buys you, since you would probably normally wouldn't be looking 
to have that inferred or determined by another piece of code, but 
if boolean values are used, you at least have that flexibility 
without having to use static if to provide the function multiple 
times.

- Jonathan M Davis
Jul 28 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


It's the other way round. pragma(inline) has currently *three* 
behaviors:

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

There is no way to represent those as a single boolean.

  — David
Jul 28 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/28/15 5:24 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three* behaviors:

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

 There is no way to represent those as a single boolean.


Ugh. And pragma(inline) doesn't mean what you would think it means. This 
is not a very good API for it, it's going to confuse everyone.

-Steve
Jul 28 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/28/15 5:28 PM, Steven Schveighoffer wrote:

 On 7/28/15 5:24 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three* behaviors:

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it means. This
 is not a very good API for it, it's going to confuse everyone.


Er.. nevermind. I misread the docs. I think.

-Steve
Jul 28 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 28 July 2015 at 21:29:45 UTC, Steven Schveighoffer 
wrote:

 On 7/28/15 5:28 PM, Steven Schveighoffer wrote:

 On 7/28/15 5:24 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis 
 wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently 
 *three* behaviors:

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it 
 means. This
 is not a very good API for it, it's going to confuse everyone.


 Er.. nevermind. I misread the docs. I think.


I do think it is terribly confusing. pragma(inline) does not 
cause any inlining by itself at all. It just means to let the 
compiler do what it normally does (i.e. try to inline if -inline 
is specified).

  — David
Jul 28 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/28/15 6:12 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 21:29:45 UTC, Steven Schveighoffer wrote:

 On 7/28/15 5:28 PM, Steven Schveighoffer wrote:

 On 7/28/15 5:24 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three*
 behaviors:

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it means. This
 is not a very good API for it, it's going to confuse everyone.


 Er.. nevermind. I misread the docs. I think.


 I do think it is terribly confusing. pragma(inline) does not cause any
 inlining by itself at all. It just means to let the compiler do what it
 normally does (i.e. try to inline if -inline is specified).


OK, that is what I first thought. Then I thought it meant that for that 
function, it works as if -inline was passed on the command line (i.e. 
try to inline if possible, if not, don't worry about it). So you are 
saying the first interpretation is correct?

That means pragma(inline) is essentially useless.

-Steve
Jul 30 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer 
wrote:

 OK, that is what I first thought. Then I thought it meant that 
 for that function, it works as if -inline was passed on the 
 command line (i.e. try to inline if possible, if not, don't 
 worry about it). So you are saying the first interpretation is 
 correct?

 That means pragma(inline) is essentially useless.


Well, if pragmas work with : like attributes (I don't know if 
they do), then pragma(inline) would be a way to undo a 
pragma(inline, true) or pragma(inline, false) on specific 
functions, similar to how many folks want !final or final(false) 
after using final:, but if : doesn't work with pragmas, then 
yeah, it's totally useless.

- Jonathan M Davis
Jul 30 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/30/15 4:37 PM, Jonathan M Davis wrote:

 On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:

 OK, that is what I first thought. Then I thought it meant that for
 that function, it works as if -inline was passed on the command line
 (i.e. try to inline if possible, if not, don't worry about it). So you
 are saying the first interpretation is correct?

 That means pragma(inline) is essentially useless.


 Well, if pragmas work with : like attributes (I don't know if they do),
 then pragma(inline) would be a way to undo a pragma(inline, true) or
 pragma(inline, false) on specific functions, similar to how many folks
 want !final or final(false) after using final:, but if : doesn't work
 with pragmas, then yeah, it's totally useless.


Without knowing the rules what does this do:

pragma(inline):
int foo()
{
    return 1;
}

If anyone reads this and says he intuitively thinks "oh, that will mean 
you have to pass -inline on the command line to get it inlined," I think 
he is not being truthful.

-Steve
Jul 31 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 July 2015 at 14:06, Steven Schveighoffer via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 7/30/15 4:37 PM, Jonathan M Davis wrote:


 On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer wrote:


 OK, that is what I first thought. Then I thought it meant that for
 that function, it works as if -inline was passed on the command line
 (i.e. try to inline if possible, if not, don't worry about it). So you
 are saying the first interpretation is correct?

 That means pragma(inline) is essentially useless.


 Well, if pragmas work with : like attributes (I don't know if they do),
 then pragma(inline) would be a way to undo a pragma(inline, true) or
 pragma(inline, false) on specific functions, similar to how many folks
 want !final or final(false) after using final:, but if : doesn't work
 with pragmas, then yeah, it's totally useless.


 Without knowing the rules what does this do:

 pragma(inline):
 int foo()
 {
    return 1;
 }

 If anyone reads this and says he intuitively thinks "oh, that will mean
 you have to pass -inline on the command line to get it inlined," I think he
 is not being truthful.

 -Steve


Yeah...  I'm sticking to my earlier assertion on this.

Using -(f)inline on the command line should not be read as being related to
pragma(inline).  The pragma is explicit request by the user which says that
this function should be inlined.

So the way I read it, is that uninlineable functions marked with
pragma(inline) should come with whatever diagnostics necessary to heed off
the user from using it in situations that are impossible.

When I say this, I mean things like:
- Naked functions
- Functions with D-style asm
- Functions with calls to alloca()
- Variadic functions

With everything else, you can either expect the function to be inlined...
or not - it really does depend on whether or not the compiler sees it as
worth it, but at least you don't get errors about it.  It's at this point
that pragma(inline, true) comes into the picture.

Regards
Iain.
Jul 31 2015
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 30 July 2015 at 18:41:51 UTC, Steven Schveighoffer 
wrote:

 So you are saying the first interpretation is correct?


As far as I can see, this is what the implementation currently 
does, yes.

  — David
Jul 30 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 28 July 2015 at 22:12:21 UTC, David Nadlinger wrote:

 I do think it is terribly confusing. pragma(inline) does not 
 cause any inlining by itself at all. It just means to let the 
 compiler do what it normally does (i.e. try to inline if 
 -inline is specified).


I suppose people were frustrated with attributes which can't be 
negated, so they requested default inlining policy just for the 
heck of it, it probably doesn't have a compelling use case? 
Decide on inlining in generic way?
Jul 31 2015
prev sibling parent reply "Brandon Ragland" <brags callmemaybe.com> writes:
On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer 
wrote:

 On 7/28/15 5:24 PM, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis 
 wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three* 
 behaviors:

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it 
 means. This is not a very good API for it, it's going to 
 confuse everyone.

 -Steve


I don't think it's terrible confusing, just deceptive.

If pragma(inline) means "attempt to inline just like the -inline 
compile time attribute" then it's just an ugly way of repeating 
yourself.

In my opinion it shouldn't be any kind of expression. How often 
will ever need evaluate an expression for inlining? The hint: 
Once in 3 programmer's lifetimes.

It should be something like:

 inline  noinline

Or some other pragma or attribute.

If I want inlining, I want inlining. If the compiler cannot 
inline, throw an exception. Otherwise, do as I ask. I'm not here 
to joke around with a compiler. I'm here to develop my programs 
and have the compiler be on my side, not against me.
Jul 28 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 28 July 2015 at 23:55:00 UTC, Brandon Ragland wrote:

 On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer 
 wrote:

 On 7/28/15 5:24 PM, David Nadlinger wrote:

 […]

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it 
 means. This is not a very good API for it, it's going to 
 confuse everyone.

 -Steve


 I don't think it's terrible confusing, just deceptive.

 If pragma(inline) means "attempt to inline just like the 
 -inline compile time attribute" then it's just an ugly way of 
 repeating yourself.


Unless I misread the source, it does not mean that at all. 
Instead, it leads to the same behavior as if no pragma(inline) 
was specified at all, i.e. use the normal heuristics if -inline 
is specified, and do not do any inlining otherwise.

  — David
Jul 29 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 July 2015 at 20:34, David Nadlinger via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Tuesday, 28 July 2015 at 23:55:00 UTC, Brandon Ragland wrote:


 On Tuesday, 28 July 2015 at 21:28:30 UTC, Steven Schveighoffer wrote:


 On 7/28/15 5:24 PM, David Nadlinger wrote:


 [=E2=80=A6]

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

 There is no way to represent those as a single boolean.


 Ugh. And pragma(inline) doesn't mean what you would think it means. Thi=






s

 is not a very good API for it, it's going to confuse everyone.

 -Steve


 I don't think it's terrible confusing, just deceptive.

 If pragma(inline) means "attempt to inline just like the -inline compile
 time attribute" then it's just an ugly way of repeating yourself.


 Unless I misread the source, it does not mean that at all. Instead, it
 leads to the same behavior as if no pragma(inline) was specified at all,
 i.e. use the normal heuristics if -inline is specified, and do not do any
 inlining otherwise.

  =E2=80=94 David


Of course, team sanity will do something different... Won't we? :o)

Well, for me it seems more obvious to let the GCC backend warn against any
functions that were marked pragma(inline) by the user, but will never be
inlined for one reason or another.

Regards
Iain
Jul 29 2015
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 29 July 2015 at 18:34:34 UTC, David Nadlinger wrote:

 Unless I misread the source, it does not mean that at all. 
 Instead, it leads to the same behavior as if no pragma(inline) 
 was specified at all, i.e. use the normal heuristics if -inline 
 is specified, and do not do any inlining otherwise.

  — David


Does anybody know what happens when you annotate a unittest with 
pragma(inline, true)? Unittests are functions as well, right?
Jul 29 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis 
 wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three* 
 behaviors:

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

 There is no way to represent those as a single boolean.


The second two states can be. So, you can turn inlining on and 
off by feeding it a template argument or the result of a function 
or something. But it is true that you'd be stuck with a static if 
in the case that you just wanted to set it to the default 
behavior. I don't know what you'd do to be able to take an 
argument for all three though - maybe a string or just some known 
integral value?

I don't know how much it really matters ultimately though, since 
I expect that for the most part, the folks who are going to be 
using this pragma won't be using it generically.

Personally, I very much doubt that I'll ever use it, since I've 
never worked on code that cared about performance so much that 
you _had_ to force inlining somewhere. The compiler usually does 
a good enough job (though that's with C++ compilers; who knows 
how well dmd does).

- Jonathan M Davis
Jul 28 2015
parent "Brandon Ragland" <brags callmemaybe.com> writes:
On Tuesday, 28 July 2015 at 21:30:11 UTC, Jonathan M Davis wrote:

 On Tuesday, 28 July 2015 at 21:24:31 UTC, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 15:56:52 UTC, Jonathan M Davis 
 wrote:

 It[Accepting Booleans]'s far more flexible in generic code.


 It's the other way round. pragma(inline) has currently *three* 
 behaviors:

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

 There is no way to represent those as a single boolean.


 The second two states can be. So, you can turn inlining on and 
 off by feeding it a template argument or the result of a 
 function or something. But it is true that you'd be stuck with 
 a static if in the case that you just wanted to set it to the 
 default behavior. I don't know what you'd do to be able to take 
 an argument for all three though - maybe a string or just some 
 known integral value?

 I don't know how much it really matters ultimately though, 
 since I expect that for the most part, the folks who are going 
 to be using this pragma won't be using it generically.

 Personally, I very much doubt that I'll ever use it, since I've 
 never worked on code that cared about performance so much that 
 you _had_ to force inlining somewhere. The compiler usually 
 does a good enough job (though that's with C++ compilers; who 
 knows how well dmd does).

 - Jonathan M Davis


Even for an application that you would assume does a fine job, if 
you know, via profiling or unittests that a certain expression or 
method takes a bit of time due to excessive calls, it might just 
shave off a noticeable amount of time.

Case in point: live dynamic report generation. Let's say we have 
millions of records from a database and we want to process them 
and churn out a report. If this is done live, this could easily 
take minutes depending on the calculations and manipulations you 
need to do. If a call to a method is made every record, you could 
easily shave off 10-30 seconds with forcing an inline. And 
believe me, 10-30 seconds makes a huge difference when you're 
waiting around for 5+ minutes or more.

There's also time sensitive trading systems that don't want to be 
half a second slow, due to all that money they want now, now , 
now.

You'd be surprised how many places you could save a few seconds 
here or there with a smart inline attribute that the compiler 
might have missed.

It's been my experience that DMD doesn't really do a good job 
with this. GDC is much much better, but DMD truly lacks luster 
with inlining.
Jul 28 2015
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 28 July 2015 at 15:15:58 UTC, Steven Schveighoffer 
wrote:

 the only thing I can thing of is that true/false are (or have 
 the potential to be in this context) expressions, which means 
 one could use compile-time logic to specify inlining. The same 
 wouldn't be true of arbitrary identifiers.


Of course it would, e.g. if they are strings, or constants/types 
defined in druntime.

  — David
Jul 28 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 28 Jul 2015 11:15:58 -0400, Steven Schveighoffer wrote:


 the only thing I can thing of is that true/false are (or have the
 potential to be in this context) expressions, which means one could use
 compile-time logic to specify inlining. The same wouldn't be true of
 arbitrary identifiers.


pragma(inline, "always");
pragma(inline, "never");
pragma(inline, "whatever");

this way argument still can be expression, and compiler is able to test=20
for correct argument too (for semantic analyzer there is almost no=20
difference between testing for some given id and for some given string).

yet "that ship has sailed", i think.=
Jul 28 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:

 yet "that ship has sailed", i think.


It hasn't yet. 2.068.0 will be the first release to include the 
pragma.

  — David
Jul 29 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 29 Jul 2015 18:35:36 +0000, David Nadlinger wrote:


 On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:

 yet "that ship has sailed", i think.


=20
 It hasn't yet. 2.068.0 will be the first release to include the pragma.


but one has to convince Walter, and it's not the easiest thing to do. ;-)=
Aug 04 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:mp86be$8f2$1 digitalmars.com...


 the only thing I can thing of is that true/false are (or have the 
 potential to be in this context) expressions, which means one could use 
 compile-time logic to specify inlining. The same wouldn't be true of 
 arbitrary identifiers.


That's why the proposal was for strings, not arbitrary identifiers.
Jul 31 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 26 July 2015 at 21:58:02 UTC, Brandon Ragland wrote:

 On Saturday, 24 August 2013 at 19:13:49 UTC, jerro wrote:

 On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:

 I just started writing an emulator in D for some fun; I 
 needed an
 application to case-study aggressive performance 
 characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want 
 to put it out
 there again... if I were shipping this product, I would NEED 
 forceinline +
 force-not-inline.


 You could use GDC and  attribute("forceinline") and
  attribute("noinline"). But I agree it would be nice to have
 something like that as a part of the language.


 Don't mean to resurrect an old thread but was working n a 
 project to replace a few C programs today, that are 
 time-sensitive and process fairly large batches of files, for 
 live-use.

 Was looking for a way to inline a few function calls that could 
 shave a few seconds off my run time today, ended up using GDC 
 attribute flags but was hoping the language had this feature.

 Though I understand it intelligently decides, sometimes it 
 doesn't do so well.

 Case in point might be a call that at first glance doesn't get 
 called often, but when in production, gets called thousands of 
 times. That could be massive savings if it were able to force 
 inline.


It's in, merged a couple months ago, will be in the upcoming 
2.068 release:

https://github.com/D-Programming-Language/dmd/pull/4723
Jul 26 2015
prev sibling parent "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
On Saturday, 17 March 2012 at 22:53:58 UTC, Manu wrote:

 I just started writing an emulator in D for some fun; I needed 
 an
 application to case-study aggressive performance 
 characteristics in
 hot-loop situations.
 I know this has come up time and time again, but I just want to 
 put it out
 there again... if I were shipping this product, I would NEED 
 forceinline +
 force-not-inline.


I don't know if it's possible right now with GDC/LDC but did you 
try PGO+LTO ?
Just curious.
Jul 27 2015