www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inlining or not inlining...

reply spir <denis.spir gmail.com> writes:
Hello,

Walter states that inline annotations are useless, since programmers cannot 
generally know which function /should/ be inlined --depending on a variety of 
factors, inlining may in fact be counter-productive.
I totally agree, even more after having (superficially) explored the topic 
(mainly in LLVM docs). This point of view addresses one face of the question: 
namely when a given piece of code will be "factored out" into a separate 
function in any case, and we just wish it could be inlined.

What if instead we wish this piece code inline in any case, even at the price 
of code duplication when it's used by several functions. The point is then 
different: we want to know whether the compiler will inline it, else we do it 
ourselves.

If the compiler does, we are free to write the source in the optimal form for 
clarity; else, we are left and doing our best to prevent code obfuscation. This 
issue often happens to me, maybe, because I have high expectations on clarity, 
so that I tend to make functions for anything conceptually representing a whole 
task, even if tiny, even if used only by a single client func. (Structured 
programming is before all, for me, a tool for clarity, not to avoid code dup.)

Thus, at best, we would need to know a bit about criteria used by the compiler 
for deciding whether to inline or not; provided a doc explaining this is at all 
readable by people who do not have the compiler-writer gene.
Aside that, let us imagine an inline annotation beeing, not a request for 
inlining, but a request for compiler warning emission when inlining would not 
be applied to a given annotated func. Then, programmers would at least know, 
beeing thus able to choose on an informed basis.
Complement to that may be a little (and hopefully clear) how-to guide on "best 
chances to get a func inlined". This howto would start by describing most 
common and/or most critical criteria for the compiler to /not/ inline a given 
func. Then, a short set of negative & positive examples actually generating or 
not the fatal warning.
As a nice side-effect, such a doc may help & make clear some schemes of 
(in)efficiency, in general, even for an inlined piece of code. (*)

Denis

By the way, I would love a [rather big] tutorial on efficiency -- what do you 
think?
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 09 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1420.1297253687.4748.digitalmars-d puremagic.com...
 By the way, I would love a [rather big] tutorial on efficiency -- what do 
 you think?
That would be great. Funny timing on your mentioning that, though: I just noticed today that one of my D programs appears to run half as fast when compiled with "-release -O" as it does with "-debug". And no, that's not a typo or a juxtaposition. Haven't really dug into the matter, though.
Feb 09 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 This howto would start by describing most common and/or most critical criteria
for the compiler to /not/ inline a given func.
Well if I read the code correctly: - inline assembler - variadic functions (string s, ...) - synchronized - imported functions - functions with closure vars - virtual functions that aren't final - functions with out, ref or static array parameters - functions with more than 250 elementary expressions
Feb 09 2011
next sibling parent Trass3r <un known.com> writes:
At least back in 2010:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Is_there_a_way_to_get_a_list_of_functions_that_get_inlined_by_dmd_18798.html#N18810
Feb 09 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/09/2011 03:53 PM, Trass3r wrote:
 This howto would start by describing most common and/or most critical criteria
for the compiler to /not/ inline a given func.
Well if I read the code correctly: - inline assembler - variadic functions (string s, ...) - synchronized - imported functions - functions with closure vars - virtual functions that aren't final - functions with out, ref or static array parameters - functions with more than 250 elementary expressions
Very interesting. What do you think about the compiler telling "Function f in module m not inlined"? Guess it would (just) need a flag 'inliningRequested' set by the parser in whatever structure represents a func. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 09 2011
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 09/02/2011 12:14, spir wrote:
 Hello,

 Walter states that inline annotations are useless, since programmers cannot
generally know
 which function /should/ be inlined --depending on a variety of factors,
inlining may in
 fact be counter-productive.
<snip> I hate not being able to force functions to be inline. A consequence is that you can't fully interface certain APIs without an extra .lib over what would be needed in C(++). Stewart.
Feb 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Stewart Gordon wrote:
 On 09/02/2011 12:14, spir wrote:
 Hello,

 Walter states that inline annotations are useless, since programmers 
 cannot generally know
 which function /should/ be inlined --depending on a variety of 
 factors, inlining may in
 fact be counter-productive.
<snip> I hate not being able to force functions to be inline. A consequence is that you can't fully interface certain APIs without an extra .lib over what would be needed in C(++).
You cannot force inlining in C(++) either. The inline keyword is only a suggestion. I'm not understanding your last comment that a .lib would be required. That's not correct, as since you're supplying the full source anyway (needed for inlining), just compile in that source from the command line. No lib step is needed.
Feb 10 2011
next sibling parent reply so <so so.so> writes:
 You cannot force inlining in C(++) either. The inline keyword is only a  
 suggestion.

 I'm not understanding your last comment that a .lib would be required.  
 That's not correct, as since you're supplying the full source anyway  
 (needed for inlining), just compile in that source from the command  
 line. No lib step is needed.
Hinting wasn't enough, every major implementation have a forceinline extension now. So you know if something you asked is inlined or not.
Feb 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 You cannot force inlining in C(++) either. The inline keyword is only 
 a suggestion.

 I'm not understanding your last comment that a .lib would be required. 
 That's not correct, as since you're supplying the full source anyway 
 (needed for inlining), just compile in that source from the command 
 line. No lib step is needed.
Hinting wasn't enough, every major implementation have a forceinline extension now. So you know if something you asked is inlined or not.
There are all kinds of extensions popular in C++, but they are not part of Standard C++.
Feb 11 2011
parent so <so so.so> writes:
 There are all kinds of extensions popular in C++, but they are not part  
 of Standard C++.
That is because if they don't support an extension (where standard failed to provide), people would switch to different compiler that would. If you mean there are many things a language can't possibly cope with, where it could be supported by extensions and inline is one of them, you would be right and i agree on this point completely.
Feb 12 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 10 February 2011 22:35:34 Walter Bright wrote:
 Stewart Gordon wrote:
 On 09/02/2011 12:14, spir wrote:
 Hello,
 
 Walter states that inline annotations are useless, since programmers
 cannot generally know
 which function /should/ be inlined --depending on a variety of
 factors, inlining may in
 fact be counter-productive.
<snip> I hate not being able to force functions to be inline. A consequence is that you can't fully interface certain APIs without an extra .lib over what would be needed in C(++).
You cannot force inlining in C(++) either. The inline keyword is only a suggestion.
True. However, IIRC -O3 in gcc forces inlining, so in some cases you _can_ force it (though that's obviously compiler-specific), but forcing inlining with -O3 does it for _everything_, so it's not exactly precision instrument. Regardless, I would _hope_ that the compiler would be smart enough to make intelligent choices about inlining. That's probably one of those areas that can always be improved however. - Jonathan M Davis
Feb 10 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Regardless, I would _hope_ that the compiler would be smart enough to make 
 intelligent choices about inlining. That's probably one of those areas that
can 
 always be improved however.
I agree completely. All compilers could use better register allocation algorithms, too.
Feb 11 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 11/02/2011 06:35, Walter Bright wrote:
<snip>
 I hate not being able to force functions to be inline. A consequence is that
you can't
 fully interface certain APIs without an extra .lib over what would be needed
in C(++).
You cannot force inlining in C(++) either. The inline keyword is only a suggestion.
But is the inline keyword guaranteed to prevent a duplicate symbol error at link time when multiple modules contain this same function after preprocessing?
 I'm not understanding your last comment that a .lib would be required. That's
not correct,
 as since you're supplying the full source anyway (needed for inlining), just
compile in
 that source from the command line. No lib step is needed.
OK, so a .lib isn't strictly necessary, a .obj will do. But for an example of what I'm on about, consider the many #define macros in the C headers of the Windows API. In D, these become functions, and you can't tell the compiler to inline them. Therefore you have to compile the Windows API bindings as modules in their own right, and then link them in, whereas in C(++) you need only to compile and link your own source files (along with a few standard Windows .libs). Consequently, all these functions might end up in the .exe even though they are never used, either because the application code never uses them or because the compiler has inlined them where they are used. Stewart.
Feb 15 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:
 Thus, at best, we would need to know a bit about criteria used by the 
 compiler for deciding whether to inline or not; provided a doc 
 explaining this is at all readable by people who do not have the 
 compiler-writer gene.
 Aside that, let us imagine an inline annotation beeing, not a request 
 for inlining, but a request for compiler warning emission when inlining 
 would not be applied to a given annotated func. Then, programmers would 
 at least know, beeing thus able to choose on an informed basis.
 Complement to that may be a little (and hopefully clear) how-to guide on 
 "best chances to get a func inlined". This howto would start by 
 describing most common and/or most critical criteria for the compiler to 
 /not/ inline a given func. Then, a short set of negative & positive 
 examples actually generating or not the fatal warning.
 As a nice side-effect, such a doc may help & make clear some schemes of 
 (in)efficiency, in general, even for an inlined piece of code. (*)
While in isolation that's a good idea, how far should it be taken? Should the compiler emit information on which variables wound up in which registers, and why? What about other of the myriad of compiler optimizations? Also, if you're willing to look at the assembler output of the compiler, it's pretty trivial to see if a function was inlined or not. If you're interested in optimizing at that level, I think it would make sense to get familiar with the asm output.
 By the way, I would love a [rather big] tutorial on efficiency -- what 
 do you think?
My advice is to start with -cov and -profile.
Feb 10 2011
next sibling parent reply so <so so.so> writes:
 While in isolation that's a good idea, how far should it be taken?  
 Should the compiler emit information on which variables wound up in  
 which registers, and why? What about other of the myriad of compiler  
 optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control? A few times i have seen comparisons here to similar languages and in most of them the inlining was the reason (only) for the inferior performance. I agree it would be awesome if the compilers had the ability to chose the best method, but comparisons show sometimes the opposite, i don't know maybe they are hand-picked for some reason.
Feb 10 2011
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/10/2011 10:53 PM, so wrote:
 While in isolation that's a good idea, how far should it be taken? Should the
compiler emit information on which
 variables wound up in which registers, and why? What about other of the myriad
of compiler optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control? A few times i have seen comparisons here to similar languages and in most of them the inlining was the reason (only) for the inferior performance. I agree it would be awesome if the compilers had the ability to chose the best method, but comparisons show sometimes the opposite, i don't know maybe they are hand-picked for some reason.
Nope.. that'd be choosing the 'right' algorithm.
Feb 10 2011
parent reply so <so so.so> writes:
On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts <braddr puremagic.com>  
wrote:

 On 2/10/2011 10:53 PM, so wrote:
 While in isolation that's a good idea, how far should it be taken?  
 Should the compiler emit information on which
 variables wound up in which registers, and why? What about other of  
 the myriad of compiler optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control? A few times i have seen comparisons here to similar languages and in most of them the inlining was the reason (only) for the inferior performance. I agree it would be awesome if the compilers had the ability to chose the best method, but comparisons show sometimes the opposite, i don't know maybe they are hand-picked for some reason.
Nope.. that'd be choosing the 'right' algorithm.
Heh, yeh after that.
Feb 10 2011
parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/10/2011 11:14 PM, so wrote:
 On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts <braddr puremagic.com> wrote:
 
 On 2/10/2011 10:53 PM, so wrote:
 While in isolation that's a good idea, how far should it be taken? Should the
compiler emit information on which
 variables wound up in which registers, and why? What about other of the myriad
of compiler optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control? A few times i have seen comparisons here to similar languages and in most of them the inlining was the reason (only) for the inferior performance. I agree it would be awesome if the compilers had the ability to chose the best method, but comparisons show sometimes the opposite, i don't know maybe they are hand-picked for some reason.
Nope.. that'd be choosing the 'right' algorithm.
Heh, yeh after that.
After that it becomes heavily dependent on what the bottle neck is. It's rare that I've felt the need to mess with inlining. But I'm sure this sort of thing is also highly variable based on type of applications, code style, language, etc.
Feb 10 2011
parent so <so so.so> writes:
 But I'm sure this sort of thing is also highly variable based on type of  
 applications, code style, language, etc.
Indeed it is, for example you won't hear much complaints from game developers because they rely on GPU for most of the computations these days, but there are other areas where cpu is used intensively, you can be sure just because of this simple issue they won't use D. And the funny part is that it doesn't hurt anyone having this with the specific features D has (annotations), it is a win-win. Also i am not talking about c++ "inline" keyword here, if you go check a few open-source cpu heavy projects, they mostly use compiler specific forced inlines. inline // either inline this or give me an error why you can't / won't.
Feb 11 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 While in isolation that's a good idea, how far should it be taken? 
 Should the compiler emit information on which variables wound up in 
 which registers, and why? What about other of the myriad of compiler 
 optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control?
No, not even close. The first step is figure out where your program is slow, and then why it is slow. For example, if it is slow because foo() is being called 1,000,000 times, you'll get a one thousand times speedup if you can tweak your algorithms so that it is only called 1,000 times.
 A few times i have seen comparisons here to similar languages and in 
 most of them the inlining was the reason (only) for the inferior 
 performance.
 I agree it would be awesome if the compilers had the ability to chose 
 the best method, but comparisons show sometimes the opposite, i don't 
 know maybe they are hand-picked for some reason.
Certainly, the inliner in dmd can be improved.
Feb 11 2011
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/11/2011 12:37 AM, Walter Bright wrote:
 so wrote:
 While in isolation that's a good idea, how far should it be taken? Should the
compiler emit information on which
 variables wound up in which registers, and why? What about other of the myriad
of compiler optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control?
No, not even close. The first step is figure out where your program is slow, and then why it is slow. For example, if it is slow because foo() is being called 1,000,000 times, you'll get a one thousand times speedup if you can tweak your algorithms so that it is only called 1,000 times.
 A few times i have seen comparisons here to similar languages and in most of
them the inlining was the reason (only)
 for the inferior performance.
 I agree it would be awesome if the compilers had the ability to chose the best
method, but comparisons show sometimes
 the opposite, i don't know maybe they are hand-picked for some reason.
Certainly, the inliner in dmd can be improved.
Improving the inline is one of the many itches I intend to scratch at some point. I did some a while back to get my feet wet. I'll get back to it again at some point. Currently it only does the really easy stuff, and that's clearly not good enough in the long run.
Feb 11 2011
prev sibling parent reply so <so so.so> writes:
 No, not even close. The first step is figure out where your program is  
 slow, and then why it is slow. For example, if it is slow because foo()  
 is being called 1,000,000 times, you'll get a one thousand times speedup  
 if you can tweak your algorithms so that it is only called 1,000 times.
I think we are talking about two different things, i don't mean locating the cause of the bottleneck, it is of course the most logical thing to do. Assume we know the problem, a function that has been reduced to simplest case, still compiler for some reason didn't do the inlining and we need every bit. Wrappers and frequent matrix, vector operations are a very serious examples that inlining is must. Now, it doesn't matter how easy or hard, have could we get around this? This is a great for an annotation.
Feb 11 2011
parent so <so so.so> writes:
 Wrappers and frequent matrix, vector operations are -a- very serious  
 examples that inlining is must. Now, it doesn't matter how easy or hard,  
 -have- +how+ could we get around this?
 This is a great +excuse+ for an annotation.
duh... how hard to synchronize brain, hands and eyes...
Feb 11 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 07:53 AM, so wrote:
 While in isolation that's a good idea, how far should it be taken? Should the
 compiler emit information on which variables wound up in which registers, and
 why? What about other of the myriad of compiler optimizations?
Isn't Inlining by far the most important (most practical) optimization among those that actually we can control? A few times i have seen comparisons here to similar languages and in most of them the inlining was the reason (only) for the inferior performance. I agree it would be awesome if the compilers had the ability to chose the best method, but comparisons show sometimes the opposite, i don't know maybe they are hand-picked for some reason.
I recently read a study using a dozen test cases to compare optimisations performed by 3 C compiler (IIRC: gcc, a win product, and an LLVM one). Very instructive, and even more surprising for me. In every case, some optimsation was done by a compiler that others did not, or conversely. This let me think for a while... how come? Don't compiler authors know, more or less, what kinds or optimisation "tactics" *exist* in given situations? and thus are performed by others. Strange. If this is the case, then the world of programming definitely needs a public knowledge base dedicated to compiler technique, esp. on optimisation. A wiki, indeed. denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 While in isolation that's a good idea, how far should it be taken? Should the 
 compiler emit information on which variables wound up in which registers, and 
 why? What about other of the myriad of compiler optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start. With CommonLisp compiler when you compile with max optimization levels the compiler gives many comments that explain why it isn't optimizing something, including some forms of inlining, see for example: http://shootout.alioth.debian.org/u32/program.php?test=fasta&lang=sbcl&id=3 Part of the comments: ; --> CEILING MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION IF VALUES 1+ ; ==> ; (+ SB-C::TRU 1) ; ; note: forced to do GENERIC-+ (cost 10) ; unable to do inline fixnum arithmetic (cost 1) because: ; The first argument is a INTEGER, not a FIXNUM. ; The result is a (VALUES INTEGER &OPTIONAL), not a (VALUES FIXNUM &REST T). ; unable to do inline fixnum arithmetic (cost 2) because: ; The first argument is a INTEGER, not a FIXNUM. ; The result is a (VALUES INTEGER &OPTIONAL), not a (VALUES FIXNUM &REST T). ; etc. Another similar kind of useful notes from the compiler: http://d.puremagic.com/issues/show_bug.cgi?id=5070 Bye, bearophile
Feb 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 While in isolation that's a good idea, how far should it be taken? Should the 
 compiler emit information on which variables wound up in which registers, and 
 why? What about other of the myriad of compiler optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start.
Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered?
Feb 11 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/11/2011 08:11 PM, Walter Bright wrote:
 bearophile wrote:
 While in isolation that's a good idea, how far should it be taken? Should
 the compiler emit information on which variables wound up in which
 registers, and why? What about other of the myriad of compiler optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start.
Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered?
Because we do not ask for it ;-) Joke apart, I would love that too, on tiny test apps indeed. Why not? Since the decision-taking exist (and is certainly well structured around its criteria), why not allow it writing out its "reasoning"? About inline, note that no-one asks for information on every potentially inlinable func, blindly. But having a way to know that about /this/ func one is wondering about would be great: just append inline to it, recompile, et voilà! you know :-) (provided you can interpret the output, but it's another story) <side-note> If I were a compiler writer, no doubt my code would hold snippets dedicated to spitting out such information, on need. For myself, as a testing tool to check the code really does what I mean. This is integral part of my coding style. Else, how can I know? Checking the ASM indeed can tell you, but it seems to me far more heavy & complicated than following the trace of a "reasoning", and tells nothing about where/why/how the encoded logic fails. Then, if this can be useful to users... <side-note> Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 About inline, note that no-one asks for information on every potentially 
 inlinable func, blindly. But having a way to know that about /this/ func one
is 
 wondering about would be great: just append  inline to it, recompile, et
voilà! 
 you know :-) (provided you can interpret the output, but it's another story)
If that's your purpose then I suggest a name as isInlinable :-) Bye, bearophile
Feb 11 2011
parent spir <denis.spir gmail.com> writes:
On 02/11/2011 10:08 PM, bearophile wrote:
 spir:

 About inline, note that no-one asks for information on every potentially
 inlinable func, blindly. But having a way to know that about /this/ func one is
 wondering about would be great: just append  inline to it, recompile, et
voilà!
 you know :-) (provided you can interpret the output, but it's another story)
If that's your purpose then I suggest a name as isInlinable :-)
Fine :-) denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:
 On 02/11/2011 08:11 PM, Walter Bright wrote:
 bearophile wrote:
 While in isolation that's a good idea, how far should it be taken? 
 Should
 the compiler emit information on which variables wound up in which
 registers, and why? What about other of the myriad of compiler 
 optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start.
Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered?
Because we do not ask for it ;-)
Actually, that is a good reason.
 Joke apart, I would love that too, on tiny test apps indeed. Why not? 
 Since the decision-taking exist (and is certainly well structured around 
 its criteria), why not allow it writing out its "reasoning"?
 
 About inline, note that no-one asks for information on every potentially 
 inlinable func, blindly. But having a way to know that about /this/ func 
 one is wondering about would be great: just append  inline to it, 
 recompile, et voilà! you know :-) (provided you can interpret the 
 output, but it's another story)
 
 <side-note>
 If I were a compiler writer, no doubt my code would hold snippets 
 dedicated to spitting out such information, on need. For myself, as a 
 testing tool to check the code really does what I mean. This is integral 
 part of my coding style. Else, how can I know? Checking the ASM indeed 
 can tell you, but it seems to me far more heavy & complicated than 
 following the trace of a "reasoning", and tells nothing about 
 where/why/how the encoded logic fails.
 Then, if this can be useful to users...
 <side-note>
 
 Denis
Feb 11 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 bearophile wrote:
 While in isolation that's a good idea, how far should it be taken? Should the 
 compiler emit information on which variables wound up in which registers, and 
 why? What about other of the myriad of compiler optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start.
Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered?
Some answers: - I am not asking for this information because it is harder to use for me. If a function was inlined or not is simpler to use for me. - In my D1 code I have found two or more problems caused by failed inlining. So this is of my interest. - If you want to optionally give the register information to the programmer, then do it. I am not going to stop you :-) Some people need this information, like when you implement the little kernels of a very fast FFT. - Register allocation on 32 bit CPUs is not the same as on 64 bit ones. On 64 bit you have many more registers (and you have SSE registers, and now AVX too), so in many situations the register pressure is lower. - There are two groups of register allocation algorithms. The very fast ones, and the more precise ones. You even have perfect ones. Experience has shown that the difference in runtime performance between the precise algorithm and the perfect ones is often about 5% (this measured on LLVM(. This means that with LLVM you will probably never see a significant improvement of automatic register allocation, because it's as good as it gets, it's kind of a solved problem. In JITs like in the JavaVM you have register allocation algorithms that are less precise but faster. Here there is space for possible future improvements. And then, there are the special situations, like implementing those little FFT kernels, or when you want to compile a functional language like Haskell into assembly. In such situations even the very good automatic register allocation algorithms are not good enough. In this case information about register allocation is useful, but this is a very specialized usage. The need to know about inlining is in my opinion more common. Bye, bearophile
Feb 11 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 There are two groups of register allocation algorithms. The very
 fast ones, and the more precise ones. You even have perfect ones. Experience
 has shown that the difference in runtime performance between the precise
 algorithm and the perfect ones is often about 5% (this measured on LLVM(.
 This means that with LLVM you will probably never see a significant
 improvement of automatic register allocation, because it's as good as it
 gets, it's kind of a solved problem.
I've seen those papers on "precise" or even "perfect" register allocation. They're only precise within a certain set of assumptions the compiler makes about usage patterns. Those assumptions are, just that, assumptions. For example, assumptions are made about how many times this loop executes relative to that loop. An asm programmer who knows his salt can do a better job, because he knows what the usage patterns are. Of course it's only rarely worth his while to do so, but nevertheless, calling such an algorithm "perfect" is misleading.
Feb 11 2011
prev sibling next sibling parent reply so <so so.so> writes:
 Register allocation is far more important than inlining. Why not give  
 information about why a variable was not enregistered?
I am sorry Walter but your stance on this more politic than a practical fact, it is not you, sounds like you secured a professorship!. :)
Feb 11 2011
parent reply so <so so.so> writes:
 Register allocation is far more important than inlining. Why not give  
 information about why a variable was not enregistered?
I am sorry Walter but your stance on this more politic than a practical fact, it is not you, sounds like you secured a professorship!. :)
Now i started to see the reasons of your stance, reading some of the old posts about this you are right directing them to asm output. Because what they ask is doesn't make sense, this is a low level optimization/query and if they can't even find out from asm output (also this is something needs to be queried that way), this is the last of their concerns. Again, you are absolutely right if your reasoning is that things like can_inline please_tell_me_if_you_can is just nonsense. Real issue pops up when you know if compiler is inlining or not but have no say in the decision process. You simply need a mechanism to sometimes state, "i need all i can get here, i know what i am doing, inline and save me a function call cost." And unlike many other low level optimizations this is something we can control. If you are against this reasoning, i don't have any idea why D has inline assembly, which again targets a very small audience.
Feb 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
so wrote:
 If you are against this reasoning, i don't have any idea why D has 
 inline assembly, which again targets a very small audience.
The inline assembler is soooo much easier to deal with than the miserable, fugly assemblers found on the various systems. The Linux as assembler is designed to crush all the joy out of writing in asm. The Microsoft assemblers change behavior constantly, breaking everything. The inline assembler can't do everything a standalone assembler can, but what it does it does well enough, and is a pleasure (to me) to use.
Feb 13 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 The inline assembler can't do everything a standalone assembler can, but what
it 
 does it does well enough, and is a pleasure (to me) to use.
The D inline assembler has another purpose you have not underlined: it's a didactic tool to learn some assembly without nothing but the normal D compiler. Delphi too allows inline asm, and I know some people that have used just that to learn and use assembly. The evolution of species is not a constant flow of changes. After a period of quick change, species often froze in many of their characteristics, and then they adapt only in a small ways, or in "alternative" ways, while keeping most of their original design. In the meantime new species branch sideways, and most of the actual fundamental changes happen during this side branching. To me something quite similar seems to happen to software technology: people that program in assembly seems furiously attached to ancient ways to use assembly, even if new and new languages and their ecosystems have invented better and better ways to program. There is not much intrinsic in the asm language that forces people to not define and use a good type system on asm instructions to catch programming bugs, to indent asm code well, to use a modern IDE on asm code, and so on. But most asm programmers seem uninterested in those new tools and new possibilities. All this is quite fascinating. Bye, bearophile
Feb 13 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 There is not much intrinsic in the asm language that forces people
 to not define and use a good type system on asm instructions to
 catch programming bugs, to indent asm code well, to use a modern
 IDE on asm code, and so on.
All of this has been done, and caught on to a huge degree. They called that asm+types language "C" (especially Digital Mars C, which has an excellent inline asm; I can't imagine I would have gotten anything done back in the day using the shitty gcc asm). Of course, we've improved upon that even more, and called it "D". If you're writing any large amount assembly today, it is often because you specifically don't want those kind of things because they either get in the way or are just useless for the task at hand. For the parts when such things are desirable, you write it in C and friends.
Feb 13 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 All of this has been done, and caught on to a huge degree.
 They called that asm+types language "C"
This is part of what I was referring to: http://www.cs.cornell.edu/talc/ Bye, bearophile
Feb 13 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Walter:
 
 The inline assembler can't do everything a standalone assembler can, but
 what it does it does well enough, and is a pleasure (to me) to use.
The D inline assembler has another purpose you have not underlined: it's a didactic tool to learn some assembly without nothing but the normal D compiler. Delphi too allows inline asm, and I know some people that have used just that to learn and use assembly.
Yes, you're right.
 The evolution of species is not a constant flow of changes. After a period of
 quick change, species often froze in many of their characteristics, and then
 they adapt only in a small ways, or in "alternative" ways, while keeping most
 of their original design. In the meantime new species branch sideways, and
 most of the actual fundamental changes happen during this side branching.
 
 To me something quite similar seems to happen to software technology: people
 that program in assembly seems furiously attached to ancient ways to use
 assembly, even if new and new languages and their ecosystems have invented
 better and better ways to program.
 
 There is not much intrinsic in the asm language that forces people to not
 define and use a good type system on asm instructions to catch programming
 bugs, to indent asm code well, to use a modern IDE on asm code, and so on.
 But most asm programmers seem uninterested in those new tools and new
 possibilities. All this is quite fascinating.
In that vein, it is exceedingly miserable that assemblers do not accept struct declarations in C format. I always have to painstakingly translate them, and double check that all the offsets and alignment are correct. What a pain.
Feb 13 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/14/2011 04:42 AM, Walter Bright wrote:
 In that vein, it is exceedingly miserable that assemblers do not accept struct
 declarations in C format. I always have to painstakingly translate them, and
 double check that all the offsets and alignment are correct. What a pain.
Does D's inline asm allow that? "In the same vein", what about a low-level language with (un)named tuples? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 14 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 Does D's inline asm allow that?
I don't think so (but I don't know what you are able to do with static structs defined outside the asm block).
 "In the same vein", what about a low-level language with (un)named tuples?
I have suggested some kind of annotation to allow D std.typecons.tuple to support structural typing. And I think Andrei has shown some interest on it. Bye, bearophile
Feb 14 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/14/11, bearophile <bearophileHUGS lycos.com> wrote:
 spir:

 Does D's inline asm allow that?
I don't think so (but I don't know what you are able to do with static structs defined outside the asm block).
I think the asm in DMD is the same one used in DMC, so this page should be helpfull: http://www.digitalmars.com/ctg/ctgInlineAsm.html
Feb 14 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:
 On 02/14/2011 04:42 AM, Walter Bright wrote:
 In that vein, it is exceedingly miserable that assemblers do not 
 accept struct
 declarations in C format. I always have to painstakingly translate 
 them, and
 double check that all the offsets and alignment are correct. What a pain.
Does D's inline asm allow that?
Yes, in that it is aware of declarations in the D code.
Feb 14 2011
prev sibling parent so <so so.so> writes:
On Mon, 14 Feb 2011 00:58:48 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 so wrote:
 If you are against this reasoning, i don't have any idea why D has  
 inline assembly, which again targets a very small audience.
The inline assembler is soooo much easier to deal with than the miserable, fugly assemblers found on the various systems. The Linux as assembler is designed to crush all the joy out of writing in asm. The Microsoft assemblers change behavior constantly, breaking everything. The inline assembler can't do everything a standalone assembler can, but what it does it does well enough, and is a pleasure (to me) to use.
That was not my question. I am not against inline asm, quite contrary it is one of the best things in D. I just tried to point out that both should be provided because of similar reasons.
Feb 13 2011
prev sibling parent "JimBob" <jim bob.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ij41q1$1j1q$2 digitalmars.com...
 bearophile wrote:
 While in isolation that's a good idea, how far should it be taken? 
 Should the compiler emit information on which variables wound up in 
 which registers, and why? What about other of the myriad of compiler 
 optimizations?
Inlining is an important optimization, so give this information to the programmer is a good start.
Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered?
Whether either should be left up to the compiler should be down the merits of actually doing so, not on whether the other one is or not. Nobody wants to be able to specify register allocation. At least ive not seen anyone ask for it. So thats an easy decision. It's a feature nobody would use even if it were included. Inlining is completly different. Lots of people want the ability to control it, or at least to be able to be notified when it doesnt happen. You say look at the asm output? So everytime the compiler gets updated, or somthing changes, we dig through how much source/dissambly to check everything is still getting inlined? Or you say that the compiler can make better decision than the programmer? Maybe it can most of the time but even very mature compilers still spit out awful code sometimes. I thought D was supposed to be a pragmatic language? Well maybe that pragmatism should extend to realizing that compilers dont always get it right.
Feb 12 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/11/2011 07:32 AM, Walter Bright wrote:
 spir wrote:
 Thus, at best, we would need to know a bit about criteria used by the
 compiler for deciding whether to inline or not; provided a doc explaining
 this is at all readable by people who do not have the compiler-writer gene.
 Aside that, let us imagine an inline annotation beeing, not a request for
 inlining, but a request for compiler warning emission when inlining would not
 be applied to a given annotated func. Then, programmers would at least know,
 beeing thus able to choose on an informed basis.
 Complement to that may be a little (and hopefully clear) how-to guide on
 "best chances to get a func inlined". This howto would start by describing
 most common and/or most critical criteria for the compiler to /not/ inline a
 given func. Then, a short set of negative & positive examples actually
 generating or not the fatal warning.
 As a nice side-effect, such a doc may help & make clear some schemes of
 (in)efficiency, in general, even for an inlined piece of code. (*)
While in isolation that's a good idea, how far should it be taken? Should the compiler emit information on which variables wound up in which registers, and why? What about other of the myriad of compiler optimizations? Also, if you're willing to look at the assembler output of the compiler, it's pretty trivial to see if a function was inlined or not. If you're interested in optimizing at that level, I think it would make sense to get familiar with the asm output.
People possibly interested in the question of inlining (or more generally factors of (in)efficiency) must start somehow, granted. But making it even more difficult than necessary, while we all know it is inherently a very complex topic, does not bring much, don't you think? In this case, I guess emitting such an information is very easy, since the compiler already needs to compute whether or not to inline. Or am I wrong and overlook a relevant point? On the other side, the feedback brought is extremely valuable; it allows learning by trial & error, and/or guided by a little howto as evoked above. Both count, and personal experience primes (I guess). I have actually programmed some pieces of code in ASM (a very long time ago), so I know it is possible for normal people. But the barrier is still very high; and anyway one approach does not prevent the other, instead compiler feedback is very complementary to asm "contemplation" ;-) Don't you think so? Even more, the compiler routine deciding on inlining probably has, at least partly, a form of checklist, so that the compiler could even say /why/... which would help much when decoding asm by giving some hint on /what/ to look for. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 People possibly interested in the question of inlining (or more generally 
 factors of (in)efficiency) must start somehow, granted. But making it even
more 
 difficult than necessary, while we all know it is inherently a very complex 
 topic, does not bring much, don't you think?
 In this case, I guess emitting such an information is very easy, since the 
 compiler already needs to compute whether or not to inline. Or am I wrong and 
 overlook a relevant point? On the other side, the feedback brought is
extremely 
 valuable; it allows learning by trial & error, and/or guided by a little howto 
 as evoked above. Both count, and personal experience primes (I guess).
I have added an enhancement request, where you are able to add more comments like those ones: http://d.puremagic.com/issues/show_bug.cgi?id=5563 Bye, bearophile
Feb 11 2011
prev sibling next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Jonathan M Davis Wrote:

 On Thursday 10 February 2011 22:35:34 Walter Bright wrote:
 Stewart Gordon wrote:
 On 09/02/2011 12:14, spir wrote:
 Hello,
 
 Walter states that inline annotations are useless, since programmers
 cannot generally know
 which function /should/ be inlined --depending on a variety of
 factors, inlining may in
 fact be counter-productive.
<snip> I hate not being able to force functions to be inline. A consequence is that you can't fully interface certain APIs without an extra .lib over what would be needed in C(++).
You cannot force inlining in C(++) either. The inline keyword is only a suggestion.
True. However, IIRC -O3 in gcc forces inlining, so in some cases you _can_ force it (though that's obviously compiler-specific), but forcing inlining with -O3 does it for _everything_, so it's not exactly precision instrument. Regardless, I would _hope_ that the compiler would be smart enough to make intelligent choices about inlining. That's probably one of those areas that can always be improved however.
I also think that this decision should be left to the compiler. The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.
Feb 11 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/11/2011 09:33 AM, Jim wrote:
 Regardless, I would _hope_ that the compiler would be smart enough to make
  intelligent choices about inlining. That's probably one of those areas that
can
  always be improved however.
I also think that this decision should be left to the compiler. The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.
Agreed; but what about having the compiler tell you, on demand, "func 'f' at line #l in module 'm' was not inlined" ? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
parent reply Jim <bitcirkel yahoo.com> writes:
spir Wrote:

 On 02/11/2011 09:33 AM, Jim wrote:
 Regardless, I would _hope_ that the compiler would be smart enough to make
  intelligent choices about inlining. That's probably one of those areas that
can
  always be improved however.
I also think that this decision should be left to the compiler. The inline keyword was deemed useful for the same reason that symbols had to be declared before their use (causing the C/C++ header hell) -- it's easier to implement such a compiler.
Agreed; but what about having the compiler tell you, on demand, "func 'f' at line #l in module 'm' was not inlined" ?
I rarely need to go that low-level. My hope is that the compiler will sort this out in the end. Give it some time, or effort to have these optimizations implemented in the compiler.
Feb 11 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jim:

 I rarely need to go that low-level.
Two times I have had D1 code that was too much slow compared to equivalent C code. After profiling and some changes I have understood that the cause was an important missing inline. With a list of the inlined functions (as done by CommonLisp some compilers, see the enhancement request in Bugzilla), this search becomes quicker.
 My hope is that the compiler will sort this out in the end. Give it some time,
or effort to have these optimizations implemented in the compiler.
The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow). Bye, bearophile
Feb 11 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 07:08 PM, bearophile wrote:
 Jim:

 I rarely need to go that low-level.
Two times I have had D1 code that was too much slow compared to equivalent C code. After profiling and some changes I have understood that the cause was an important missing inline. With a list of the inlined functions (as done by CommonLisp some compilers, see the enhancement request in Bugzilla), this search becomes quicker.
 My hope is that the compiler will sort this out in the end. Give it some time,
or effort to have these optimizations implemented in the compiler.
The LLVM back-end of LDC is able to inline much more, but even here a list of inlined/not inlined functions helps. D is almost a system language, so sometimes you need to go lower level (or you just need a program that's not too much slow).
To me the relevant aspect is not that much practical effect, but understanding how/why/what is inlined by (hopefully good) compilers. Learning about that, even if not much put in practice (I don't intend to write the next big language's compiler ;-) can only improve coding skills and, say... help and stop shooting in the dark. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
prev sibling parent reply Jim <bitcirkel yahoo.com> writes:
bearophile Wrote:
 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).
If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?
Feb 11 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Jim Wrote:

 bearophile Wrote:
 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).
If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?
Just had another idea.. A function would know statically whether it has been inlined or not. If inlined it could choose to propagate this attribute to any of its own callees. Not sure it would be useful though, just thinking aloud..
Feb 11 2011
parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 02/11/11 14:26, Jim wrote:
 Jim Wrote:
 
 bearophile Wrote:
 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).
If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?
Just had another idea.. A function would know statically whether it has been inlined or not. If inlined it could choose to propagate this attribute to any of its own callees. Not sure it would be useful though, just thinking aloud..
And at this point what once seemed a simple thing starts to show its complexity teeth. Suddenly there are all this adjunct features to be provided in order to make it properly useful. Don't get me wrong, I'd actually like having all this... but I'm not sure of the cost in compiler complexity (and likely slowdown) and language bloat. But, here's some notions: == I really want foo() to be inlined, if even remotely possible! == pragma( inline ) int foo () { ... } == I'll be calling foo(), and I'd like it inlined if possible == int bar () { pragma( inline, foo ); // ... auto x = foo(); } == I'm foo(), and I'd like to know if I am being inlined == int foo () { pragma( inline, true ) { // inline code } pragma( inline, false ) { // ordinary code } } -- or if we ever get that 'meta' namespace some of us want -- int foo () { static if ( meta.inlined ) { // inline code } else { // ordinary code } } My chief complaint with my own notions is that 'pragma(inline' ends up with three different forms. This just isn't typical of a pragma. -- Chris N-S
Feb 11 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/11/2011 10:22 PM, Christopher Nicholson-Sauls wrote:
 On 02/11/11 14:26, Jim wrote:
 Jim Wrote:

 bearophile Wrote:
 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).
If forced inlining is to be supported I think it would be good idea to also let the _caller_ decide whether to inline a function. The compiler could simply find the function definition, perhaps parameterize it, and then insert it. Should it not be able to inline almost any function if asked to?
Just had another idea.. A function would know statically whether it has been inlined or not. If inlined it could choose to propagate this attribute to any of its own callees. Not sure it would be useful though, just thinking aloud..
And at this point what once seemed a simple thing starts to show its complexity teeth. Suddenly there are all this adjunct features to be provided in order to make it properly useful. Don't get me wrong, I'd actually like having all this... but I'm not sure of the cost in compiler complexity (and likely slowdown) and language bloat. But, here's some notions: == I really want foo() to be inlined, if even remotely possible! == pragma( inline ) int foo () { ... } == I'll be calling foo(), and I'd like it inlined if possible == int bar () { pragma( inline, foo ); // ... auto x = foo(); } == I'm foo(), and I'd like to know if I am being inlined == int foo () { pragma( inline, true ) { // inline code } pragma( inline, false ) { // ordinary code } } -- or if we ever get that 'meta' namespace some of us want -- int foo () { static if ( meta.inlined ) { // inline code } else { // ordinary code } } My chief complaint with my own notions is that 'pragma(inline' ends up with three different forms. This just isn't typical of a pragma. -- Chris N-S
All of this is hardly related to the simple feature I initially asked for: string escString (string s) tellmeifnotinlined { s2 = s.replace("\n","\\n"); s2 = s.replace("\t","\\t"); return s2; } void show (X x) { // ... use escString ... } ==> Warning: function 'escString' in module 'foo' (line 123) was not inlined. (or else it was actually inlined) Which (I guess) is not that a big deal since the compiler needs to decide anyway. I just wish to be informed of the result of the decision procedure, only in case of 'no'. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
next sibling parent so <so so.so> writes:
 All of this is hardly related to the simple feature I initially asked  
 for:

 	string escString (string s)  tellmeifnotinlined {
 	    s2 = s.replace("\n","\\n");
 	    s2 = s.replace("\t","\\t");
              return s2;
          }
 	void show (X x) {
 	    // ... use escString ...
          }
 ==>
 	Warning: function 'escString' in module 'foo' (line 123) was not  
 inlined.
 	(or else it was actually inlined)

 Which (I guess) is not that a big deal since the compiler needs to  
 decide anyway. I just wish to be informed of the result of the decision  
 procedure, only in case of 'no'.

 Denis
Guys, i don't know what are you trying or why you simply seem to avoid my reasoning on this, if you don't need this (and you all seem not use it) why are you trying to find solutions for the problems that doesn't affect you directly? :) Unline a few of you said this is not a complex problem and actually it hasn't been complex in C++ either for again, practical purposes. Standard C++ says: For class/struct methods, compiler inlines things and it is aware of most of them wrappers so you don't need "inline" keyword there. But still it does have this keyword as a hint to use other methods. This has never been enough and all major compilers now have forced inlines. (always_inline, __forceinline...) What they do is forcing to compiler inline a function and if compiler won't do it it issues an error to state why. All is needed is just i said in another post: inline // inline or issue and error why you won't. - simple - serves practical purposes rather than fiction - it does no harm to anyone - so easy to implement - it is sometimes advanced but still something controllable Now please what is wrong here someone enlighten me. Thanks.
Feb 11 2011
prev sibling parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
 
 All of this is hardly related to the simple feature I initially asked for:
 
     string escString (string s)  tellmeifnotinlined {
         s2 = s.replace("\n","\\n");
         s2 = s.replace("\t","\\t");
             return s2;
         }
     void show (X x) {
         // ... use escString ...
         }
 ==>
     Warning: function 'escString' in module 'foo' (line 123) was not
 inlined.
     (or else it was actually inlined)
 
 Which (I guess) is not that a big deal since the compiler needs to
 decide anyway. I just wish to be informed of the result of the decision
 procedure, only in case of 'no'.
 
 Denis
I could really go for that, myself. Occasionally I've wanted such a beasty. I really do think it makes more sense as a pragma() than an attribute unto itself, though. -- Chris N-S
Feb 12 2011
parent spir <denis.spir gmail.com> writes:
On 02/12/2011 10:46 AM, Christopher Nicholson-Sauls wrote:
 All of this is hardly related to the simple feature I initially asked for:

      string escString (string s)  tellmeifnotinlined {
          s2 = s.replace("\n","\\n");
          s2 = s.replace("\t","\\t");
              return s2;
          }
      void show (X x) {
          // ... use escString ...
          }
 ==>
      Warning: function 'escString' in module 'foo' (line 123) was not
 inlined.
      (or else it was actually inlined)

 Which (I guess) is not that a big deal since the compiler needs to
 decide anyway. I just wish to be informed of the result of the decision
 procedure, only in case of 'no'.

 Denis
I could really go for that, myself. Occasionally I've wanted such a beasty. I really do think it makes more sense as a pragma() than an attribute unto itself, though.
Agreed, since it's not a language feature properly speaking. Anyway... Denis -- _________________ vita es estrany spir.wikidot.com
Feb 12 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jim:

 If forced inlining is to be supported
spir was asking for a list of functions that the compiled has inlined, not for a forced inlining functionality. Bye, bearophile
Feb 11 2011
parent spir <denis.spir gmail.com> writes:
On 02/11/2011 09:49 PM, bearophile wrote:
 Jim:

 If forced inlining is to be supported
spir was asking for a list of functions that the compiled has inlined, not for a forced inlining functionality.
You are (nearly) right, Bearophile. More precisely, I rather wish inline on a given func to output a compiler message if said func is *not* inlined, due to some criterion the compiler uses to decide; at best, some hint about said criterion. I certainly do /not/ ask for forced inlining. (But others take the thread and speak of what they wish...) Denis -- _________________ vita es estrany spir.wikidot.com
Feb 11 2011
prev sibling parent reply Jim <bitcirkel yahoo.com> writes:
spir Wrote:

 On 02/11/2011 09:49 PM, bearophile wrote:
 Jim:

 If forced inlining is to be supported
spir was asking for a list of functions that the compiled has inlined, not for a forced inlining functionality.
You are (nearly) right, Bearophile. More precisely, I rather wish inline on a given func to output a compiler message if said func is *not* inlined, due to some criterion the compiler uses to decide; at best, some hint about said criterion. I certainly do /not/ ask for forced inlining. (But others take the thread and speak of what they wish...)
Sorry about that, but I think that is a closely related discussion. inline is certainly a verb -- even imperative mood, so not just asking for information. Why do you need information if you can't affect the outcome? bearophile Wrote:
 D is almost a system language, so sometimes you need to go lower level (or you
just need a program that's not too much slow).
And it's true. To fit that niche you need control. D proudly supports inline assembler, after all... Why not function inlining? Also, the meta-namespace is intriguing: static if( meta.inlined ) { ... } A function would know statically whether it was inlined, perhaps on request by the caller of the function. The meta-namespace could provide a lot of useful information.
Feb 12 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Feb 12 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
spir Wrote:

 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-)
Glasnost! :) How about the meta-namespace then: static if( meta.inlined ) { writeln("got it!"); }
Feb 12 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 02/12/2011 12:42 PM, Jim wrote:
 spir Wrote:

 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-)
Glasnost! :) How about the meta-namespace then: static if( meta.inlined ) { writeln("got it!"); }
I vote +++ for the idea of meta in general. (And tons of + for real type objects as plain D data structures). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 12 2011
prev sibling parent reply ivan <pavlov pavlov.org> writes:
Jim Wrote:

 spir Wrote:
 
 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-)
Glasnost! :) How about the meta-namespace then: static if( meta.inlined ) { writeln("got it!"); }
Why not: void foo() { printf("da\n"); } const bool bar = glasnost.inlined(foo); or const bool bar = __glasnost << inlined!foo;
Feb 12 2011
next sibling parent ivan <pavlov pavlov.org> writes:
ivan Wrote:

 Jim Wrote:
 
 spir Wrote:
 
 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-)
Glasnost! :) How about the meta-namespace then: static if( meta.inlined ) { writeln("got it!"); }
Why not: void foo() { printf("da\n"); } const bool bar = glasnost.inlined(foo); or const bool bar = __glasnost << inlined!foo;
In general we need traits for discovering all optimizations: pragma(msg, __traits.optimizations.tupleof(foo).stringof); // results as an example in: ("loop unfolding", "sse2 multiplication", "inline-strong-pass", "tail-call optimization")
Feb 12 2011
prev sibling parent Jim <bitcirkel yahoo.com> writes:
ivan Wrote:

 Jim Wrote:
 
 spir Wrote:
 
 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-)
Glasnost! :) How about the meta-namespace then: static if( meta.inlined ) { writeln("got it!"); }
Why not: void foo() { printf("da\n"); } const bool bar = glasnost.inlined(foo); or const bool bar = __glasnost << inlined!foo;
Ideally, you also want to be able to request inlining at the place of calling a function, not only at the definition of the function.
Feb 12 2011
prev sibling parent reply so <so so.so> writes:
On Sat, 12 Feb 2011 13:20:36 +0200, spir <denis.spir gmail.com> wrote:

 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  
  inline is certainly a verb -- even imperative mood, so not just asking  
 for information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-) Denis
This is to all of you. Inlining is not a toy, knowing if a function is inlined or not has no practical purposes in the sense you are asking, or any other for that matter. This is a low level optimization, again it is not a toy to play with, and D being a system language (where function call is cheap) makes this even more meaningless. Now i am repeating this the third time seem people just ignore it: . Inlining problem in D has never been about determining a function is inlined or not. Walter 100% right on this, go check the freaking asm output. . The problem is that we have "no" say in the decision process, and this is a serious matter in some high performance areas, serious that goes to decide if they will use a language or not. So please lets focus on the problem and not waste the time on irrelevant things/changes/decisions.
Feb 12 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/13/2011 04:13 AM, so wrote:
 On Sat, 12 Feb 2011 13:20:36 +0200, spir <denis.spir gmail.com> wrote:

 On 02/12/2011 12:15 PM, Jim wrote:
 Sorry about that, but I think that is a closely related discussion.  inline
 is certainly a verb -- even imperative mood, so not just asking for
 information.
 Why do you need information if you can't affect the outcome?
I want to know it. First, because it's valuable information in and by itself. Second, because it teaches me something. Third, because I can then possibly decide to not factor out (may be wrong, but still, I can measure...). Glasnost for compilers! ;-) Denis
This is to all of you. Inlining is not a toy, knowing if a function is inlined or not has no practical purposes in the sense you are asking, or any other for that matter. This is a low level optimization, again it is not a toy to play with, and D being a system language (where function call is cheap) makes this even more meaningless.
How many times do I need to repeat I do not want to force inlining? Or what else are you talking about? Instead, I want to /know/. Example use: ensure trivial externalisation dist below will be properly inlined back by the compiler. I factorise out dist for code clarity, but do not want this to cause stupid performance penalty. Cases: * the compiler shut up --> ok * the compiler says 'no' -- possibly 'because ...' ~ I can decide to unfactor out ~ I can measure, and realise cost of func call is nothing compared to square root ~ I may learn something from additional info ~ I may realise the case is not as trivial as it seems ~ I may learn about highering chances of inlining // billions of them struct Point { float x,y; float d; this (float x, float x) { this.x = x; this.y = y; // inline or not inline? this.d = dist(x,y); pragma (inlineinfo) { static float dist (int x, int y) { return squareRoot(x*x + y*y); } } } Denis -- _________________ vita es estrany spir.wikidot.com
Feb 12 2011
parent reply so <so so.so> writes:
 How many times do I need to repeat I do not want to force inlining? Or  
 what else are you talking about?
And this is why it doesn't make sense. What are we doing here? Are we trying to find practical solutions to real world problems or just showing how useless things D can do?
 Instead, I want to /know/. Example use: ensure trivial externalisation  
 dist below will be properly inlined back by the compiler. I factorise  
 out dist for code clarity, but do not want this to cause stupid  
 performance penalty. Cases:
 * the compiler shut up --> ok
 * the compiler says 'no' -- possibly 'because ...'
      ~ I can decide to unfactor out
      ~ I can measure, and realise cost of func call is nothing compared  
 to square root
Listen, inlining is not something to play with like that, you either want a function to be inlined or not, this simple. The reasons are straightforward. Say you have an intersection test where you optimized and such, it might contain square roots, dots, crosses whatever and nothing you can do about it anymore. It is obviously costly, costs far more than the function call cost. So far, everything as usual, compiler free to do what it believes right. But you know beforehand this block of code will run in many loops which changes the scenario, now function call is an issue. You don't care if compiler did it or not, you simply want it to be done.
      ~ I may learn something from additional info
Which will serve no purpose!
      ~ I may realise the case is not as trivial as it seems
Which again surves no purpose unlike you want it to be done.
 // billions of them
 struct Point {
      float x,y;
      float d;
      this (float x, float x) {
          this.x = x;
          this.y = y;
          // inline or not inline?
          this.d = dist(x,y);
 pragma (inlineinfo) {
      static float dist (int x, int y) {
          return squareRoot(x*x + y*y);
      }
 }
 }
If in your program flow, . this struct is to be used frequently . performance is your primary concern, . you have no other things to worry about (algorithms, other optimizations) . you know if inlining is a gain. Then you know beforehand that function should be inlined or not, otherwise knowing that has no purpose whatsoever.
Feb 12 2011
parent reply so <so so.so> writes:
Ok i stop, looks like i fail to make my point to anyone :)
Feb 12 2011
parent piotrek <starpit tlen.pl> writes:
On Sun, 13 Feb 2011 09:57:52 +0200, so wrote:

 Ok i stop, looks like i fail to make my point to anyone :)
I see your point and I agree with you. Cheers Piotrek
Feb 14 2011