On 08/01/2013 01:56 PM, bearophile wrote:
> I have not critiqued linear flow programming its, I love it and perhaps I was
> the one that has introduced it in D. In the main D newsgroup I have just said
> that in D it still causes some performance loss, even using ldc2.
That's what I meant -- your
Joseph Rushton Wakeling:
So, your critiques of component programming certainly
have merit on the performance side.
I have not critiqued linear flow programming its, I love it and
perhaps I was the one that has introduced it in D. In the main D
newsgroup I have just said that in D it still ca
On 07/31/2013 02:31 PM, bearophile wrote:
> If this resulting array is used only for a short period of time:
>
> return sequence.map!(x => x.func).array;
Just to compare, I tried rewriting the cacheing version of the neighbours()
function to use this kind of sequence. Here's the original code:
h
Joseph Rushton Wakeling:
But most likely the best compromise solution is as you
suggest a buffer, with the instruction ".dup the result
if you want it to be persistent".
In my library code often I do the opposite: I add a template
boolean switch named as "doCopy" that defaults to true. If it'
On 07/31/2013 02:31 PM, bearophile wrote:
> Then I suggest to try ldc2 too.
I haven't profiled with ldc2 yet (I will) but the broad speed tendencies are
similar. It's faster but not so much faster that I can assume the speed hit
isn't still there.
> My suggestion is to copy the implementation of
Joseph Rushton Wakeling:
No, gdmd -O -release -inline -g -profile, and then gprof to
generate the profile.
Then I suggest to try ldc2 too.
That's what I'd assumed, which was why I was so disappointed
that in this case
performance was _very_ bad. I particularly don't understand
the major G
Joseph Rushton Wakeling:
I take it you mean std.bitmanip.BitArray ... ?
Right.
I ran into some interesting problems which are probably down to
incomplete
implementation: e.g.
myBitArray.length += n;
... results in a compiler error message: myBitArray.length() is
not an lvalue
This
On 07/31/2013 01:02 AM, bearophile wrote:
> Also try to use a bitvector from Phobos instead of bool[].
I take it you mean std.bitmanip.BitArray ... ?
I ran into some interesting problems which are probably down to incomplete
implementation: e.g.
myBitArray.length += n;
... results in a comp
On 07/31/2013 01:02 AM, bearophile wrote:
> There are many ways to design a graph data structure. All of them have
> tradeoffs, they can't be very good for everything.
Sure, it's just that in this case the reference code (igraph) is _much_ more
performant. I'm keen to try and identify the major i
John Colvin:
Any chance of some nice examples of this?
Allocate a buffer somewhere, on the stack or heap, and then
instead of using a map()+array() as in that code use map()+copy()
plus a test to be sure the space is sufficient.
But in the end I don't know how much well even ldc2 will comp
On Tuesday, 30 July 2013 at 23:02:40 UTC, bearophile wrote:
Sometimes you can keep memory allocation low, performance
almost acceptable, and code easy to read using a pre-allocated
scratch space plus using map() and copy() from std.algorithm.
Any chance of some nice examples of this?
There are many ways to design a graph data structure. All of them
have tradeoffs, they can't be very good for everything.
For your benchmarks are you using the ldc2 compiler with correct
compilation switches?
map() should not allocate memory.
Sometimes lazy code is faster and sometimes it's
Hello all,
I thought I'd share some profiling results from the graph/network library that
I've been working on -- see:
https://github.com/WebDrake/Dgraph
http://braingam.es/2013/07/complex-networks-in-d/
http://braingam.es/2013/07/complex-networks-in-d-part-2-building-the-network/
I'd like to get
13 matches
Mail list logo
