Re: Profiling graph library

2013-08-01 Thread Joseph Rushton Wakeling
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:

Re: Profiling graph library

2013-07-31 Thread Joseph Rushton Wakeling
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

Re: Profiling graph library

2013-07-31 Thread bearophile
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

Re: Profiling graph library

2013-07-31 Thread Joseph Rushton Wakeling
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

Re: Profiling graph library

2013-07-31 Thread bearophile
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's

Profiling graph library

2013-07-30 Thread Joseph Rushton Wakeling
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

Re: Profiling graph library

2013-07-30 Thread bearophile
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

Re: Profiling graph library

2013-07-30 Thread John Colvin
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?

Re: Profiling graph library

2013-07-30 Thread bearophile
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

Re: Profiling graph library

2013-07-30 Thread Joseph Rushton Wakeling
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