On 12/23/16 9:23 PM, Chris Wright wrote:
The comparison to mach.d is a strawman.
The mach.d is given as an example of the approach of breaking code into
fine-grained module. No comparison is made or implied.
Then I looked at the code.
Phobos has 26 templates that would use this special syn
tldr: the performance impact of this DIP would be too small to easily
measure and only impacts 26 declarations referencing 14 templates in the
standard library anyway.
On Fri, 23 Dec 2016 18:55:25 -0500, Andrei Alexandrescu wrote:
>> I grant that everyone uses phobos, and phobos uses template co
On Saturday, 24 December 2016 at 01:38:24 UTC, safety0ff wrote:
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright
wrote:
For this D code:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &=
On 12/23/2016 5:06 PM, hardreset wrote:
I patched up the prolog code and timed it and it came out identical to my asm. I
tried the ptrdiff C-like code and that still comes out 20% slower here. I'm
compiling with...
rdmd test.d -O -release -inline
Am I missing something? How do I get the asm out
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:
For this D code:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}
Is subtraction of pointers which do not belong
On 12/23/2016 08:06 PM, hardreset wrote:
rdmd test.d -O -release -inline
This passes the three flags to test.d. Place test.d at the end.
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:
On 12/23/2016 10:03 AM, hardreset wrote:
For this D code:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}
The fo
On 12/23/2016 3:35 PM, Johan Engelen wrote:
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000; // should be `a + SIZE`, right?
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offs
On 12/23/2016 05:33 PM, Chris Wright wrote:
On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote:
Dependency-Carrying Declarations allow scalable template libraries.
template libraries
*This* is the part I hadn't noticed before, and it explains the confusion
I had.
If you *only* a
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000; // should be `a + SIZE`, right?
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}
This code is not equivalent with
On 24/12/2016 7:29 AM, Russel Winder via Digitalmars-d wrote:
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
wrote:
[…]
Except dmd's backend is far more well proven then LLVM is.
Come now that is obfuscation – you need to make good on this claim.
The LLVM backend has m
On Friday, 23 December 2016 at 22:41:28 UTC, Chris Wright wrote:
On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via
Digitalmars-d wrote:
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via
Digitalmars-d wrote:
[…]
Except dmd's backend is far more well proven then LLVM is.
Come now t
On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via Digitalmars-d wrote:
> On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
> wrote:
>> […]
>>
>> Except dmd's backend is far more well proven then LLVM is.
>
> Come now that is obfuscation – you need to make good on this cla
On Fri, 23 Dec 2016 07:59:40 -0800, Jonathan M Davis via Digitalmars-d
wrote:
> dmd compiles code faster, which is better from a development standpoint.
> Assuming that dmd and ldc are compatible enough, it makes a lot of sense
> to do most of the development with dmd and produce the actual product
On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote:
> Dependency-Carrying Declarations allow scalable template libraries.
> template libraries
*This* is the part I hadn't noticed before, and it explains the confusion
I had.
If you *only* apply this to templates, it works. The current
On 12/23/2016 05:11 PM, Walter Bright wrote:
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}
That's a neat trick, thanks hardreset (and Walter for making it
high-level). There are a bunch of places in drunt
On 12/23/2016 10:03 AM, hardreset wrote:
enum SIZE = 1;
void foo3(int* a, int* b)
{
asm
{
mov EAX,a;
mov EDX,b;
sub EDX,EAX;
mov ECX,EAX;
add ECX,SIZE*4;
l1:;
cmp EAX,ECX;
jae done;
mov EBX,[EAX];
On 12/23/2016 02:32 PM, Andrei Alexandrescu wrote:
On 12/23/2016 01:53 PM, Johan Engelen wrote:
Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure fu
My students and I are making a pass through a bunch of bugzilla issues
closing the ones that ought to be closed and marking the simple ones
with the "trivial" bug.
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIF
On 12/23/2016 01:53 PM, Johan Engelen wrote:
Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure functions... :)
Fixed. Keep destruction coming. -- A
On Friday, 23 December 2016 at 17:07:29 UTC, Atila Neves wrote:
On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:
On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is. But, all of these
issues can (and have) be solved by libraries.
On Friday, 23 December 2016 at 17:42:40 UTC, Andrei Alexandrescu
wrote:
On 12/23/2016 12:32 PM, Johan Engelen wrote:
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu
wrote:
Instead of
"Any `pure` function tha
On Friday, 23 December 2016 at 17:22:48 UTC, Kagamin wrote:
On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
In result I have to accept small obstacles and go on.
Otherwise I wouldn't go anywhere.
So the real question is: what can we do and what should we do
with the current amount
On Friday, 23 December 2016 at 18:33:52 UTC, Seb wrote:
On Friday, 23 December 2016 at 18:03:54 UTC, hardreset wrote:
I get..
456ms for unconditional
505ms for conditional
268ms for assembler
So the asm is about 40% faster than the best of the
alternatives. The point being that it's the gener
On Friday, 23 December 2016 at 18:03:54 UTC, hardreset wrote:
I get..
456ms for unconditional
505ms for conditional
268ms for assembler
So the asm is about 40% faster than the best of the
alternatives. The point being that it's the generated code not
the source that's the problem.
Has anyon
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
wrote:
> […]
>
> Except dmd's backend is far more well proven then LLVM is.
Come now that is obfuscation – you need to make good on this claim.
The LLVM backend has many, many more users than the DMD backend and the
LLVM backe
On Friday, 23 December 2016 at 16:15:44 UTC, Andrei Alexandrescu
wrote:
An interesting problem to look at:
The foreach macro (src/tk/vec.h#L62) looks like low hanging fruit
for optimization as well.
On Friday, 23 December 2016 at 16:15:44 UTC, Andrei Alexandrescu
wrote:
An interesting problem to look at:
https://github.com/dlang/dmd/pull/6352
Andrei
Ok some hand written assembler to and-assign ints...
enum SIZE = 1;
void foo3(int* a, int* b)
{
asm
{
mov EAX,a;
On 12/23/2016 12:32 PM, Johan Engelen wrote:
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu
wrote:
Instead of
"Any `pure` function that is not strongly pure cannot be memoized."
why not
"Any `pure` function
https://github.com/dlang/dlang.org/pull/1528 identifies the category
"pure factory functions" - pure functions that can be assumed to create
new mutable data, as of yet not referenced by any part in the program.
This has far-reaching consequences with regard to creating complex
immutable data
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
Instead of
"Any `pure` function that is not strongly pure cannot be
memoized."
why not
"Any `pure` function that is not strongly pure _may not be
assu
On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
In result I have to accept small obstacles and go on. Otherwise
I wouldn't go anywhere.
So the real question is: what can we do and what should we do
with the current amount of resources we have?
If you need a testing framework, try
On 12/23/2016 02:37 AM, Jacob Carlborg wrote:
On 2016-12-22 19:19, Andrei Alexandrescu wrote:
Both of these are affordable with the current language (attributes) with
changes to druntime. Who wants to take this? -- Andrei
What do you think about this idea [1]?
[1] http://forum.dlang.org/post
On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:
On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is. But, all of these
issues can (and have) be solved by libraries.
Atila
Cheers,
Piotrek
Would assert fixing take into account
On 12/23/2016 06:18 AM, Atila Neves wrote:
On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:
On 12/22/2016 12:46 PM, Piotrek wrote:
The inability to give test a name (plus selective unittesting) and
continue on failure is puzzling to me.
Both of these are affordable wi
On Friday, 23 December 2016 at 11:31:14 UTC, Stefan Koch wrote:
On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch
wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
p
On 12/21/2016 5:30 PM, Andrei Alexandrescu wrote:
Would be great to narrow this down regardless. Shouldn't be too difficult since
the penalty is so huge. Must be a pathological case we should fix anyway. --
Andrei
Not a complete solution, but should help:
https://github.com/dlang/dmd/pull/635
On Thursday, 22 December 2016 at 12:15:06 UTC, Matthias Klumpp
wrote:
But the much more important point for us is support and
maintainability. The reference compiler will have a much bigger
development team and higher focus of attention.
Bugs in frontend, phobos and most of druntime currently
On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is. But, all of these
issues can (and have) be solved by libraries.
Atila
Would assert fixing take into account it's presence in betterC
code?
Cheers,
Piotrek
Major update adding an experiment that shows the cost of top-level imports.
https://github.com/dlang/DIPs/pull/51
https://github.com/dlang/DIPs/blob/a3ef4e25cfb9f884fee29edb5553a3a2b840f679/DIPs/DIP1005.md
Relevant added text:
Another matter we investigated is how reducing top-level imports
i
On Friday, 23 December 2016 at 14:06:24 UTC, Adam D. Ruppe wrote:
Have you seen my filthy hack for getting individual unittests
to continue on failure?
http://stackoverflow.com/a/40896271/1457000
I have to say you are a master of D hacks :)
This code can potentially reprogram a CPU and break m
An interesting problem to look at:
https://github.com/dlang/dmd/pull/6352
Andrei
On Friday, December 23, 2016 14:12:54 Observer via Digitalmars-d wrote:
> On Friday, 23 December 2016 at 11:11:09 UTC, Jonathan M Davis
>
> wrote:
> > Conceptually, it makes no sense to be doing any of that sort of
> > thing in a strongly pure function, because at that point, we're
> > really talki
On Friday, December 23, 2016 14:14:41 Russel Winder via Digitalmars-d wrote:
> On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
>
> wrote:
> > […]
> >
> > Anyone who wants to use ldc can use ldc. It doesn't need to be the
> > reference
> > compiler for that. And unlike gdc, it'
On Friday, 23 December 2016 at 15:02:23 UTC, Ilya Yaroshenko
wrote:
[...]
It is not true for Mir projects, sometimes ICE occurs without
any description while LDC just works. --Ilya
Bug report for ICEs requires to much efforts because code size
should be reduced.
I found quite a few in LDC
On Friday, 23 December 2016 at 14:43:28 UTC, Chris Wright wrote:
I *think* you can do that with an ugly API and string mixins
and only needing to parse to the level of parentheses and
equality operators.
Yeah, you kinda can, or, of course, you can do stuff like
assertEquals etc. named functio
On Friday, 23 December 2016 at 14:44:41 UTC, rikki cattermole
wrote:
On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote:
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via
Digitalmars-d
wrote:
[…]
Anyone who wants to use ldc can use ldc. It doesn't need to
be the
reference
co
On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote:
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
wrote:
[…]
Anyone who wants to use ldc can use ldc. It doesn't need to be the
reference
compiler for that. And unlike gdc, it's actually pretty close to dmd.
So,
t
On Fri, 23 Dec 2016 14:20:44 +, Adam D. Ruppe wrote:
> Wouldn't it just be glorious if that magically printed:
>
> test.d(4): Assertion failure
> (a == b) is false a = 0 b = 1
I *think* you can do that with an ugly API and string mixins and only
needing to parse to the level of parenthe
On Fri, 23 Dec 2016 07:48:55 -0500, Andrei Alexandrescu wrote:
> On 12/22/16 10:31 PM, Chris Wright wrote:
>> It's two benefits for one disadvantage.
>
> One won't make decisions by taking the difference of pros and cons,
> right? -- Andrei
You'd use the weighted difference, naturally.
On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is.
I would love it, LOVE it, if assert just printed its info.
Consider the following code:
int a = 0;
int b = 1;
assert(a == b);
Wouldn't it just be glorious if that magically printed:
On Friday, 23 December 2016 at 11:11:09 UTC, Jonathan M Davis
wrote:
Conceptually, it makes no sense to be doing any of that sort of
thing in a strongly pure function, because at that point, we're
really talking functional purity.
I understand your points. I had been thinking about purity pur
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
wrote:
> […]
>
> Anyone who wants to use ldc can use ldc. It doesn't need to be the
> reference
> compiler for that. And unlike gdc, it's actually pretty close to dmd.
> So,
> there should be no problem with folks using ldc for
On Thursday, 22 December 2016 at 17:46:06 UTC, Piotrek wrote:
I don't know what other people think but the current status of
build-in unittests are #1 issue for a quick development. The
inability to give test a name (plus selective unittesting) and
continue on failure is puzzling to me.
Ha
On Wed, 2016-12-21 at 16:32 +, hardreset via Digitalmars-d wrote:
> On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer
> wrote:
> > On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
> > > Is moving to LLVM backend or LDC something that is on the
> > > roadmap?
> >
>
On 12/22/16 9:53 PM, Chris Wright wrote:
In point of fact, selective and static imports should be *faster* than
Andrei's way. Consider:
static import myapp.users, std.socket;
bool isUserOnline(myapp.users.User user, std.socket.Socket socket);
This has to locate a declaration named `User` in
On 12/22/16 9:53 PM, Chris Wright wrote:
bool isUserOnline(User user, Socket userSocket)
import myapp.users, std.socket;
Has changed to
with (import myapp.users, std.socket)
bool isUserOnline(User user, Socket userSocket);
Andrei
On 12/22/16 10:31 PM, Chris Wright wrote:
It's two benefits for one disadvantage.
One won't make decisions by taking the difference of pros and cons,
right? -- Andrei
On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch
wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
phobos-unittests with "" are run.
(Which would previously be coun
On Thursday, 22 December 2016 at 17:46:06 UTC, Piotrek wrote:
On Thursday, 22 December 2016 at 09:10:53 UTC, Walter Bright
wrote:
On 12/21/2016 11:24 PM, Walter Bright wrote:
[...]
Or have the compiler call a "registerUnittest()" function with
a parameter that's the pointer to the unittest i
On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei
Alexandrescu wrote:
On 12/22/2016 12:46 PM, Piotrek wrote:
The inability to give test a name (plus selective unittesting)
and
continue on failure is puzzling to me.
Both of these are affordable with the current language
(attributes) with
On Thursday, December 22, 2016 18:04:51 Observer via Digitalmars-d wrote:
> It seems to me that a pure function could have a variety of
> acceptable side effects which don't modify active memory and
> that don't work around the type system or necessarily eat
> significant CPU time, and that you pro
On Friday, December 23, 2016 07:29:49 Stefan Koch via Digitalmars-d wrote:
> On Friday, 23 December 2016 at 06:53:25 UTC, Observer wrote:
> [ ... ]
>
> A pure function MUST NOT mutate any state except what is
> reachable through it's arguments.
> This includes ANY operating system state.
That's no
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
phobos-unittests with "" are run.
(Which would previously be counted as uncompilable)
Apparently we run into a situation where the
64 matches
Mail list logo
