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