On 11/02/2011 06:35, Walter Bright wrote:
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
sug
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
On 2/14/11, bearophile 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.digital
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.
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
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
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 nothin
On Mon, 14 Feb 2011 00:58:48 +0200, Walter Bright
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
miserable, fugly assemblers f
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
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 hu
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 nor
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 designe
Ok i stop, looks like i fail to make my point to anyone :)
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 wan
On 02/13/2011 04:13 AM, so wrote:
On Sat, 12 Feb 2011 13:20:36 +0200, 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 inf
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 cop
On Sat, 12 Feb 2011 13:20:36 +0200, 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 th
"Walter Bright" 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 myr
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 i
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 i
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
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 ou
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 t
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 va
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 ra
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;
>
> 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 es
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 rea
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) {
// ... us
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!. :)
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
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?
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 :-) (
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
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
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
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
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 a
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
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).
>
>
>
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
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
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 infor
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
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 comp
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 decisi
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?
> I
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 (
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
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 c
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 informatio
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 i
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...
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 t
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?
>>
>>
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) optimi
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
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
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
On 2/10/2011 11:14 PM, so wrote:
> On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts 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,
On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts
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 compi
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 mo
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 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 var
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
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.
I hate not being abl
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 r
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.
I hate not being able to force functions to
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
-
> 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
"spir" 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 of my D program
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
(main
73 matches
Mail list logo
