On Sunday, 23 February 2014 at 07:10:32 UTC, Etienne Cimon wrote:
auto sorted = aa.sort!(Key.y => { a < b })
You can't sort an AA, as AAs are unordered. Did you mean to sort
the keys?
auto sorted = aa.keys.sort!((a, b) => a.y < b.y)();
auto filtered = aa.filter!
auto filtered = aa.k
Hello all,
This is a subject I think we've visited before, but I can't find the old
discussion threads :-(
As some of you know I'm working on a successor to std.random -- it's been put on
hold the last 8 weeks or so by country/life/work changes, but now I'm back onto
it. One of the things I
Hi
I will ask my question again.
Is there any interest in this format within the D community ?
Nick
On 20 February 2014 22:46, bearophile wrote:
> Iain Buclaw:
>
>
>> Most encoding formats use a form of discrete cosine transform, which
>> involves floating point maths.
>
>
> I don't believe this much :-(
>
:-(
I looked up vorbis (very, very) briefly way of example. Most structs
that deal wit
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
yay!
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
Is this a front-end thing or something specific to DMD? I'm
wondering because I'd like somethin
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why a pragma? Can't we use a UDA and give it some special meaning inside
the compiler?
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
yay, all for it! The DIP should probably specify what happens if
inlining fails, i.e. generate a
On 2/23/2014 4:21 AM, Mike wrote:
Is this a front-end thing or something specific to DMD? I'm wondering because
I'd like something like this for GDC and LCD when targeting ARM
microcontrollers. The inline keyword makes quite a significant performance
improvement in one of my current C++ project
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
What if you want to mark a series of functions to be inlined?
E.g. in an entire module:
-
23-Feb-2014 16:07, Walter Bright пишет:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why pragma? Also how exactly it is supposed to work:
pragma(inline, true);
... //every declaration that follows is forcibly
23-Feb-2014 16:25, Tove пишет:
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
yay, all for it! The DIP should probably specify what happens if
i
On 2/23/2014 4:25 AM, Benjamin Thaut wrote:
Why a pragma? Can't we use a UDA and give it some special meaning inside the
compiler?
This shouldn't be an attribute, it's a hint to the compiler optimizer. Pragma is
ideally suited to that.
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
Not necessary when it's inside a function.
I'd strongly favor
On 2/23/2014 4:31 AM, Andrej Mitrovic wrote:
What if you want to mark a series of functions to be inlined? E.g. in an entire
module:
-
module fast;
// ??
pragma(inline, true):
Vec vecSum();
Vec vecMul();
-
That can work because pragmas can have blocks associated with them.
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer force-inline/force-not-inline at call
On 2/23/2014 4:53 AM, ponce wrote:
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer fo
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers will have
different inlining capabilities. I think it should be a 'recommendation' to the
compile
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers
will have different inlining ca
Am 23.02.2014 13:38, schrieb Dmitry Olshansky:
23-Feb-2014 16:07, Walter Bright пОÑеÑ:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
Why pragma? Also how exactly it is supposed to work:
pragma(inline, tr
On 23/02/2014 13:07, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
Sounds good in principle. So, if I understand right, a pragma(inline, true)
anywhere inside a function adds a compiler h
23-Feb-2014 16:57, Walter Bright пишет:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers will have
different inlining capabilities. I think it shou
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
It's going to be near useless if it doesn't make sure inlining
happened.
I completely agree.
On 2014-02-16 22:05:10 +, Walter Bright said:
"However, I agree that there may well be other reasons to not have them
in Go, such as their simply not being especially useful in day-to-day
programming; but I don't have enough experience with meta-programming
to make such a judgment."
Some
I have a couple of self-implemented C++ integer sort algorithms
lying around in my codebase.
I also have a parallel merge sort on top of them that uses Intel
TBB to give some
further speedups.
I have tweaked them to also work for floats and doubles, through
some interesting bit-fiddling tips
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
+1
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers
will have different inlining ca
On 23 February 2014 14:19, Tove wrote:
> On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
>>
>> On 2/23/2014 4:25 AM, Tove wrote:
>>>
>>> The DIP should probably specify what happens if inlining fails,
>>> i.e. generate a compilation error.
>>
>>
>> I suspect that may cause proble
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
23-Feb-2014 16:57, Walter Bright пишет:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining
fails,
i.e. generate a compilation error.
I suspect that may cause problems, because differe
Today I hit two problems essentially which got me thinking about
how structs are used in D by most of the code I've seen so far.
Both problems are in:
http://d.puremagic.com/issues/show_bug.cgi?id=9513
So the RedBlackTree create excessive copies of large structs via
binaryFun, that and the ob
On Sunday, 23 February 2014 at 12:50:58 UTC, Walter Bright wrote:
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
As some of you will know Python is big in bioinformatics, HEP, finance,
signal processing and many other computational areas. Originally (and
still to some extent) Python was (and still is) used for coordination of
Fortran and C++ computations, and for rendering the visualizations.
Mathematica, R,
On Sun, 2014-02-23 at 14:09 +, "Nordlöw" wrote:
> I have a couple of self-implemented C++ integer sort algorithms
> lying around in my codebase.
What is the basic sort algorithm? Radix sort is generally seen as the
best for sorting integer values currently. But that doesn't mean there
is bett
On Sunday, 23 February 2014 at 09:55:29 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
This is a subject I think we've visited before, but I can't
find the old discussion threads :-(
As some of you know I'm working on a successor to std.random --
it's been put on hold the last 8 weeks or so
On Sunday, 23 February 2014 at 15:10:36 UTC, Russel Winder wrote:
On Sun, 2014-02-23 at 14:09 +, "Nordlöw" wrote:
I have a couple of self-implemented C++ integer sort
algorithms lying around in my codebase.
What is the basic sort algorithm? Radix sort is generally seen
as the
best for sor
On Sunday, 23 February 2014 at 16:16:48 UTC, Nordlöw wrote:
On Sunday, 23 February 2014 at 15:10:36 UTC, Russel Winder
wrote:
On Sun, 2014-02-23 at 14:09 +, "Nordlöw" wrote:
I have a couple of self-implemented C++ integer sort
algorithms lying around in my codebase.
What is the basic sort
I did some more benchmarking:
These are all using non-inplace radix sort.
This can be useful in some cases where in-place is not needed.
Performance gain increase with size input array compared to
std::sort as radix sort in "some regard" is O(n) and quick sort
is O(n*log n).
Break sizes (whe
On Sun, 2014-02-23 at 16:16 +, "Nordlöw" wrote:
[…]
>
> Should I place the code on a Github repo or send it to you by
> email?
BitBucket or GitHub work for me: if we keep this public others may join
in…
--
Russel.
On Sun, 2014-02-23 at 16:59 +, "Nordlöw" wrote:
> I did some more benchmarking:
We definitely need a benchmarking framework so as to ensure we can have
multiple runs of each datapoint calculating mean and standard deviation
for each data point, and for grouping and ANOVA. I am guessing there
i
I guess working on a branch of Phobos (std.algorithm) is
preferrable when we get to the D implementation right?
On Sun, 2014-02-23 at 17:33 +, "Nordlöw" wrote:
> I guess working on a branch of Phobos (std.algorithm) is
> preferrable when we get to the D implementation right?
I just asked effectively that question re std.parallelism on the DMD
Concurrency list, only to find I wasn't a member so the emai
On 23/02/2014 17:10, monarch_dodra wrote:
As a rule of thumb, "enforce" is not necessarily for things "user-input" but for
things "outside the programmer's control" eg: "things that can legitimately
fail", Notably, IO, threads, databases etc...
It seems to me that "enforce" is used extensively
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky
wrote:
It's going to be near useless if it doesn't make sure inlining
happened.
Part of the reason for forced inline is always inlining some
core primitives, even in debug builds.
Optional recommendation for inlining already exists
On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote:
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This
DIP proposes a simple solution.
Why a pragma? Can't we use a UDA and give it some
I guess this component would be integrated into std.algorithm
when its ready, right?
On Sunday, 23 February 2014 at 19:17:29 UTC, Nordlöw wrote:
I guess this component would be integrated into std.algorithm
when its ready, right?
If you are happy with it being in there, if the algorithm has a
nice behaviour, and it passes the existing test suite, I don't
see why it would not!
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
Seems reasonable to me.
Russel Winder:
Those in the Python side of the game disliked C and C++ co much
they created abstractions, ending up with NumPy, Cython,
ShedSkin,
Unfortunately ShedSkin is now essentially dead. And Julia could
replace Python in some usages, because of its performance.
Bye,
bearophile
On Sunday, 23 February 2014 at 17:51:34 UTC, Joseph Rushton
Wakeling wrote:
Assuming I'm right about these enforce statements being
inappropriate, I'll make a patch.
I believe you are correct, but the larger issue is that Phobos
doesn't come with a debug build. So while they probably should be
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
Ok it seems people are ok with the change, so I've merged it. It
should be easier to edit the wiki than to have to mess with DDOC
an
On 2/23/2014 5:06 AM, Joseph Rushton Wakeling wrote:
So, if I understand right, a pragma(inline, true)
anywhere inside a function adds a compiler hint to always inline this function,
while with false it's a hint to _never_ do so, and no pragma at all gives the
usual compiler-decides situation?
On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
I'll add:
pragma(inline);
That's just going to confuse people, because they'll think *this*
forces inlining.
I'd prefer 3 separate states. pragma(inline), pragma(no_inline),
and pragma(default_inline) or something like t
Am 23.02.2014 20:53, schrieb bearophile:
Russel Winder:
Those in the Python side of the game disliked C and C++ co much they
created abstractions, ending up with NumPy, Cython, ShedSkin,
Unfortunately ShedSkin is now essentially dead. And Julia could replace
Python in some usages, because of
On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
I think there should be some way to force the compiler to inline a function. As
a bonus, the error message can tell the programmer why the function could not be
inlined, allowing them to make the necessary adjustments.
Different compilers will have
On 2/23/2014 11:04 AM, Dicebot wrote:
Optional recommendation for inlining already exists - it is current default.
That is not the point of the pragma. The point of always inlining is (as Manu
explained) some functions need to be inlined even in debug mode, as the code
would otherwise be too
On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
Part of the reason for forced inline is always inlining some core primitives,
even in debug builds.
Right - and if the compiler won't do it, how does the error message help?
> I wouldn't not like to ever have to get down and look at ASM for every
On Sunday, 23 February 2014 at 20:25:11 UTC, Andrej Mitrovic
wrote:
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
Ok it seems people are ok with the change, so I've merged it.
It
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
Generally, when I optimize at that level, I have a window open
on the assembler output of the compiler and I go back and forth
on the source code until I get the shape of the assembler I
need. Having compiler messages wouldn't be
On 2/23/14, Dicebot wrote:
> This. I'd prefer anything that is not part of official spec /
> source documentation to be in wiki - it is just easier and faster
> to improve that way.
I declare the DDOC DWiki porting season officially open!
24-Feb-2014 00:46, Walter Bright пишет:
On 2/23/2014 5:07 AM, Dmitry Olshansky wrote:
Part of the reason for forced inline is always inlining some core
primitives,
even in debug builds.
Right - and if the compiler won't do it, how does the error message help?
That programmer is instantly awar
24-Feb-2014 00:40, Walter Bright пишет:
On 2/23/2014 5:01 AM, Vladimir Panteleev wrote:
I think there should be some way to force the compiler to inline a
function. As
a bonus, the error message can tell the programmer why the function
could not be
inlined, allowing them to make the necessary ad
On Sunday, 23 February 2014 at 20:00:48 UTC, Jesse Phillips wrote:
On Sunday, 23 February 2014 at 17:51:34 UTC, Joseph Rushton
Wakeling wrote:
Assuming I'm right about these enforce statements being
inappropriate, I'll make a patch.
I believe you are correct, but the larger issue is that Phobo
https://github.com/w0rp/dqt
I have been working on my generator over the past few weeks, and
extensively this weekend. It took many hours of work, but I just
got generation of D source files from SMOKE data to work. Here is
what it does and roughly how it works.
1. Earlier on, SMOKE is by a
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote:
Generally, when I optimize at that level, I have a window open
on the assembler output of the compiler and I go back and forth
on the source code until I get the shape of the assembler I
need. Having compiler messages wouldn't be
On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote:
I'll add:
pragma(inline);
That's just going to confuse people, because they'll think *this* forces
inlining.
Perhaps, but there's precedent with how align works, and how defa
On Sunday, 23 February 2014 at 19:10:08 UTC, Namespace wrote:
On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut
wrote:
Am 23.02.2014 13:07, schrieb Walter Bright:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This
DIP proposes a simple
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some reason.
Keep in mind that code changes with time and running profiler/disassembler on
every tiny change to make sure the stuff is still inlined is highly
counter-productive.
I'm aw
On Sunday, 23 February 2014 at 21:38:46 UTC, Walter Bright wrote:
On 2/23/2014 12:31 PM, Andrej Mitrovic wrote:
I'd prefer 3 separate states. pragma(inline),
pragma(no_inline), and
pragma(default_inline) or something like that.
That makes documentation with a sorted list of pragmas
impractic
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic
wrote:
E.g. the win32 guide, see here:
https://github.com/D-Programming-Language/dlang.org/pull/496
+1
On 2/23/2014 1:32 PM, Francesco Cattoglio wrote:
[...]
I addressed these three messages in another reply to Dmitry.
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due
to some reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make su
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas are
parsed.
On 2/23/2014 1:53 PM, Walter Bright wrote:
And yes, performance critical code often suffers from bit rot, and changes in
the compiler, and needs to be re-tuned now and then.
BTW, just to reiterate, there are *thousands* of optimizations the compiler may
or may not do. And yes, performance crit
On Sunday, 23 February 2014 at 21:55:11 UTC, Walter Bright wrote:
On 2/23/2014 1:32 PM, Francesco Cattoglio wrote:
[...]
I addressed these three messages in another reply to Dmitry.
Read that, and you do make a point. I am no expert on
optimization, but as far as I could tell, inlining is u
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler.
This is exactly what caused mess with http user agent info when
both browsers tried
As a compromise diagnostics about refused inlining can be added
as special output category to
https://github.com/D-Programming-Language/dmd/pull/645
24-Feb-2014 01:53, Walter Bright пишет:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some
reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make sure the stuff is still inlin
On 2/23/2014 3:00 PM, Dmitry Olshansky wrote:
You actually going against yourself with this argument - for porting you
typically suggest:
version(OS1)
...
else version(OS2)
...
else
static assert(0);
There's not much choice about that. I also suggest moving such code into
separate modules
On Sunday, 23 February 2014 at 23:49:57 UTC, Walter Bright wrote:
What makes inlining special, as opposed to, say, enregistering
particular variables?
The difference is it was explicitly told do do something and
didn't. That's insubordination.
Mike
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that
line looks awful.
If I need to support multiple compilers and if
On 2/23/2014 3:55 PM, Mike wrote:
The difference is it was explicitly told do do something and didn't. That's
insubordination.
I view this as more in the manner of providing the equivalent of runtime
profiling information to the optimizer, in indirectly saying how often a
function is execute
On Monday, 24 February 2014 at 00:33:09 UTC, Walter Bright wrote:
I suspect that elevating one particular optimization hint to
being an absolute command may not turn out well. Inlining
already has performance issues, as it may increase the size of
an inner loop beyond what will fit in the cache
Le 23/02/2014 13:07, Walter Bright a écrit :
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
I saw many times C++ developers works on applications doesn't need such
level optimization puts inline keyword or impl
On 2/22/14, 11:10 PM, Etienne Cimon wrote:
On 2014-02-23 01:27, H. S. Teoh wrote:
You can just use a struct or tuple as the AA key to achieve the same
thing.
I thought of that but it's not immediately obvious how I could achieve
sorting or filtering by a certain field
e.g.
auto sorted = aa.so
The fact that original C "inline" was designed in same
"permissive" way and is almost unused in practice (as opposed
to compiler-specific force_inline attributes) does say
something.
Do you mind to back up your "fact" with some numbers? Afaict
'inline' is more common than __attribute__((f
On 2/23/2014 4:21 PM, Tove wrote:
Inspecting asm output doesn't scale well to huge projects. Imagine simply
updating the existing codebase to use a new compiler version.
Again, this is treating 'inline' as being the only optimization that matters?
It's not even the most important - that would
On 2/22/14, 8:33, Andrej Mitrovic wrote:
On 2/22/14, simendsjo wrote:
Hehe.. "simendsjo is an exceptional D coder".
I think that page is created solely to feed our ego :)
And it creates new compliments every time you refresh. Mirror mirror
on the wall..
Jude's developer personality is
On 2/23/14, 4:07 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
This makes inlining dependent on previously-seen code. Would that make
parallel compilation more difficult?
I've always
On Sunday, 23 February 2014 at 14:36:36 UTC, Arlon Brandy wrote:
Today I hit two problems essentially which got me thinking
about how structs are used in D by most of the code I've seen
so far. Both problems are in:
http://d.puremagic.com/issues/show_bug.cgi?id=9513
So the RedBlackTree create
On Monday, 24 February 2014 at 01:12:56 UTC, Andrei Alexandrescu
wrote:
This makes inlining dependent on previously-seen code. Would
that make parallel compilation more difficult?
I've always thought the obvious/simple way would be an
attribute such as @forceinline and @noinline that applies t
On 2/23/14, 5:05 PM, Walter Bright wrote:
On 2/23/2014 4:21 PM, Tove wrote:
Inspecting asm output doesn't scale well to huge projects. Imagine simply
updating the existing codebase to use a new compiler version.
Again, this is treating 'inline' as being the only optimization that
matters? It's
On 24/02/14 06:12, Walter Bright wrote:
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas
are parsed.
Aren't true and false keywords as well?
Andrei Alexandrescu:
I've always thought the obvious/simple way would be an
attribute such as @forceinline and @noinline that applies to
individual functions.
Seems good. And what do you think the D compiler should do when
you use @forceinline and it can't inline?
Bye,
bearophile
On 2/23/2014 5:45 PM, Brad Roberts wrote:
At this point, you're starting to argue that the entire DIP isn't relevant. I
agree with the majority that if you're going to have the directive, then it
needs to be enforcement, not suggestion.
1. It provides information to the compiler about runtime
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote:
This makes inlining dependent on previously-seen code. Would that make parallel
compilation more difficult?
I don't understand the question. Inlining always depends on the compiler having
seen the function body.
I've always thought the obviou
On 2/23/2014 5:47 PM, Lionello Lunesu wrote:
On 24/02/14 06:12, Walter Bright wrote:
On 2/23/2014 1:41 PM, Namespace wrote:
pragma(inline, true);
pragma(inline, false);
pragma(inline, default);
'default' being a keyword makes for an ugly special case in how pragmas
are parsed.
Aren't true
On 23/02/14 20:07, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.
void A()
{
}
void B()
{
pragma(inline, true) A();
}
void C()
{
B();
}
Reading that code, I would guess that within B(
On Sun, 23 Feb 2014 21:05:32 -0500, Walter Bright
wrote:
On 2/23/2014 5:45 PM, Brad Roberts wrote:
At this point, you're starting to argue that the entire DIP isn't
relevant. I
agree with the majority that if you're going to have the directive,
then it
needs to be enforcement, not sugge
1 - 100 of 115 matches
Mail list logo
