On 8/23/10 19:26 PDT, dsimcha wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4264
Currently (SVN) only array() is able
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 8/23/10 19:26 PDT, dsimcha wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
The gentle and a-lot-working David Simcha has converted one of my bug
reports
into an enhancement request:
dsimcha:
So it seems like adding more and more layers of stacking causes each layer of
stacking to have progressively more overhead. This makes sense because each
layer
of stacking is likely to have a progressively worse effect on the CPU
pipeline.
The CPU can probably speculatively
== Quote from bearophile (bearophileh...@lycos.com)'s article
The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4264
Currently (SVN) only array() is able to digest iterables that define
dsimcha:
even though Map gets fully inlined when used alone.
This is what I too have found in past.
I wonder if this is a weakness of compiler inlining heuristics in general,
though.
I have a bug report open for LLVM about this :-)
is this just an ugly corner case in the imperfect
== Quote from bearophile (bearophileh...@lycos.com)'s article
The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4264
Currently (SVN) only array() is able to digest iterables that define
The gentle and a-lot-working David Simcha has converted one of my bug reports
into an enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4264
Currently (SVN) only array() is able to digest iterables that define opApply
only, but I think a few more spread support will be very
