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
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
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
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
On 2/14/11, bearophile bearophileh...@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:
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
Ok i stop, looks like i fail to make my point to anyone :)
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 s much easier to deal with than the miserable, fugly
assemblers found on the various systems.
The Linux as assembler is
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
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
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
On Mon, 14 Feb 2011 00:58:48 +0200, Walter Bright
newshou...@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 s much easier to deal with than the
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
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 ...
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;
}
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
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
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.
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
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?
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
to request inlining at the place of calling a
function, not only at the definition of the function.
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
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
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
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
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
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
--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
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
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
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
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
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 :-)
?
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
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
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!. :)
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
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
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
, 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
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
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
, 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
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
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
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
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
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
spir denis.s...@gmail.com wrote in message
news:mailman.1420.1297253687.4748.digitalmar...@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
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
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
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
-
73 matches
Mail list logo
