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