On Fri, 16 May 2014 11:51:31 -0400
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Fri, 16 May 2014 11:36:44 -0400, Jonathan M Davis via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thu, 15 May 2014 08:04:59 -0300
Ary Borenszweig
On Saturday, 17 May 2014 at 20:06:03 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
But I think that the correct solution is to improve the
compiler with regards
to lazy. The fact that lazy is so slow is a serious problem,
and enforce is
just one manifestation of it (albeit the worst
On Thu, 15 May 2014 08:04:59 -0300
Ary Borenszweig via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Isn't there a way in D to just expand:
enforce(cond, failure);
(or something with a similar syntax) to this, at compile-time:
if(!cond) throw new Exception(failure);
I
On Fri, 16 May 2014 11:36:44 -0400, Jonathan M Davis via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thu, 15 May 2014 08:04:59 -0300
Ary Borenszweig via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Isn't there a way in D to just expand:
enforce(cond,
On Thu, 15 May 2014 05:53:45 +
monarch_dodra via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
As a workaround, I'm sure we could specialize enforce without
lazy for built-in types?
No. I don't think that that would work. The problem is that you'd have to be
able to overload
On Thursday, 15 May 2014 at 06:52:44 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 15 May 2014 05:53:45 +
monarch_dodra via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
As a workaround, I'm sure we could specialize enforce without
lazy for built-in types?
On 5/15/14, 1:31 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Thu, 15 May 2014 01:29:23 +
Kapps via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 14 May 2014 at 23:50:34 UTC, Meta wrote:
On the topic of lazy, why *is* it so slow, exactly? I thought
On Wed, 14 May 2014 19:50:33 -0400, Meta jared...@gmail.com wrote:
On Wednesday, 14 May 2014 at 22:32:01 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Yeah, much as Andrei would hate to hear it (enforce was his idea, and
he quite
likes the idiom), the fact that lazy is so inefficient
I've found bench-marking my program that std.algorithm.find is
very slow on Array!T, due to the fact it iterates on a range
instead of a plain array.
I've written some search functions, which are many times faster,
is it
worth making a pull request?
http://dpaste.dzfl.pl/63b54aa27f35#
On Wednesday, 14 May 2014 at 14:24:28 UTC, Damian Day wrote:
I've written some search functions, which are many times
faster, is it
worth making a pull request?
Generally, we strive to make the algorithms in Phobos as fast as
possible even in the general case. I didn't look at the issue at
On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger wrote:
Could you post a short benchmark snippet explicitly showing the
problem?
Benchmark found here:
http://dpaste.dzfl.pl/0058fc8341830
On Wednesday, 14 May 2014 at 15:42:13 UTC, Damian Day wrote:
On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger
wrote:
Could you post a short benchmark snippet explicitly showing
the problem?
Benchmark found here:
http://dpaste.dzfl.pl/0058fc8341830
Unfortunately, I don't have the
On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger wrote:
On Wednesday, 14 May 2014 at 14:24:28 UTC, Damian Day wrote:
I've written some search functions, which are many times
faster, is it
worth making a pull request?
Generally, we strive to make the algorithms in Phobos as fast
as
On Wednesday, 14 May 2014 at 15:42:13 UTC, Damian Day wrote:
On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger
wrote:
Could you post a short benchmark snippet explicitly showing
the problem?
Benchmark found here:
http://dpaste.dzfl.pl/0058fc8341830
FYI, that implementation is
Damian Day:
Benchmark found here:
http://dpaste.dzfl.pl/0058fc8341830
Perhaps it's a problem of missed dmd inlining. So I suggest to
run the benchmark with ldc2.
Bye,
bearophile
On Wednesday, 14 May 2014 at 14:24:28 UTC, Damian Day wrote:
I've found bench-marking my program that std.algorithm.find is
very slow on Array!T, due to the fact it iterates on a range
instead of a plain array.
I've written some search functions, which are many times
faster, is it
worth
On Wednesday, 14 May 2014 at 17:57:30 UTC, monarch_dodra wrote:
BTW, this is a more general issue: Given a generic algorithm
std.foo, how can I write my own (better optimized)
object.foo, and make sure *that* is called instead?
I initially filed the issue for retro, while indeed
mentioning
On Wednesday, 14 May 2014 at 17:36:35 UTC, monarch_dodra wrote:
Adding a special case in Array.Range allows bypassing the
repeated indexing costs, but at the very least, should be
implemented in terms of find itself, eg:
Shouldn't the extra indirection just vanish into thin air once
opIndex
On Wednesday, 14 May 2014 at 20:29:52 UTC, David Nadlinger wrote:
On Wednesday, 14 May 2014 at 17:36:35 UTC, monarch_dodra wrote:
Adding a special case in Array.Range allows bypassing the
repeated indexing costs, but at the very least, should be
implemented in terms of find itself, eg:
On Wednesday, 14 May 2014 at 17:20:37 UTC, David Nadlinger wrote:
On Wednesday, 14 May 2014 at 15:42:13 UTC, Damian Day wrote:
On Wednesday, 14 May 2014 at 14:54:57 UTC, David Nadlinger
wrote:
Could you post a short benchmark snippet explicitly showing
the problem?
Benchmark found here:
On Wednesday, 14 May 2014 at 21:20:06 UTC, Kapps wrote:
That pull shows that the previous behaviour was to use enforce?
Isn't this very expensive, particularly considering that enforce
uses lazy non-scope arguments?
Yes.
On Wed, 14 May 2014 20:54:19 +
monarch_dodra via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I'm usually reluctant to add extra code when the generic case
works, but I feel we should make an exception for find.
We should avoid it where it doesn't gain us much, but the
On Wed, 14 May 2014 21:20:05 +
Kapps via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
That pull shows that the previous behaviour was to use enforce?
Isn't this very expensive, particularly considering that enforce
uses lazy non-scope arguments?
Yeah, much as Andrei would
On Wednesday, 14 May 2014 at 22:32:01 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Yeah, much as Andrei would hate to hear it (enforce was his
idea, and he quite
likes the idiom), the fact that lazy is so inefficient makes it
so that it's
arguably bad practice to use it in high
On Wednesday, 14 May 2014 at 23:50:34 UTC, Meta wrote:
On the topic of lazy, why *is* it so slow, exactly? I thought
it was just shorthand for taking a function that evaluates the
expression, and wrapping said expression in that function at
the call site. That is, I thought that:
int
On Thu, 15 May 2014 01:29:23 +
Kapps via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 14 May 2014 at 23:50:34 UTC, Meta wrote:
On the topic of lazy, why *is* it so slow, exactly? I thought
it was just shorthand for taking a function that evaluates the
On Thursday, 15 May 2014 at 04:37:16 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
enforce(cond, failure);
really should just translate to something close to
if(!cond) throw new Exception(failure);
but it doesn't do anything close to that. And as long as it
doesn't, enforce
is of
27 matches
Mail list logo
