On Thursday, 26 September 2013 at 22:03:12 UTC, bearophile wrote:
Joseph Rushton Wakeling:
T is qualified via isFloatingPoint :-)
I know, but that qualification could change in future
evolutions of your code. Strong type safety means that if you
change a type in your code, with a localized
Joseph Rushton Wakeling:
T is qualified via isFloatingPoint :-)
I know, but that qualification could change in future evolutions
of your code. Strong type safety means that if you change a type
in your code, with a localized change (like removing
isFloatingPoint at the top of your function)
On Thursday, 26 September 2013 at 21:29:42 UTC, bearophile wrote:
You also have arrays of T. Someday T could be something with
indirections :-) So minimallyInitializedArray is safer
regarding future changes in your code.
T is qualified via isFloatingPoint :-)
Joseph Rushton Wakeling:
So it's bizarre that there is a performance difference here.
Bizarre findings deserve more experiments and studies :-)
Incidentally, this was why I felt safe using uninitializedArray
for arrays of e.g. long, size_t, etc., because the only
difference at the end of t
On Thursday, 26 September 2013 at 20:56:39 UTC, bearophile wrote:
Joseph Rushton Wakeling:
I have not found this -- using minimallyInitializedArray for
the arrays of built-in types is slower than if I use
uninitializedArray.
Then minimallyInitializedArray should be improved :-)
It's odd, b
Joseph Rushton Wakeling:
I have not found this -- using minimallyInitializedArray for
the arrays of built-in types is slower than if I use
uninitializedArray.
Then minimallyInitializedArray should be improved :-)
You seem to be suggesting that using uninitializedArray could
cause general s
On Tuesday, 24 September 2013 at 22:14:30 UTC, bearophile wrote:
minimallyInitializedArray is not stupid, if the specified type
has no indirections, it's equivalent to using
uninitializedArray, but it's safer if you later change the
type. So in general it's not a good idea to use
uninitialized
Joseph Rushton Wakeling:
As an experiment I tried something along these lines -- using
uninitializedArray for most of the arrays here and
minimallyInitializedArray for p.
minimallyInitializedArray is not stupid, if the specified type
has no indirections, it's equivalent to using uninitialize
On Wednesday, 18 September 2013 at 13:39:29 UTC, bearophile wrote:
auto centrality =
minimallyInitializedArray!(typeof(return))(g.vertexCount);
centrality[] = T0;
auto stack = new size_t[g.vertexCount];
auto sigma = minimallyInitializedArray!T(g.vertexCount);
sigma[] = T0;
On Wednesday, 18 September 2013 at 17:13:28 UTC, bearophile wrote:
How many times or how often do you need to call betweenness()?
If it's called only few times or once in a while then using the
GC is good enough. But if you have to call it many millions of
times, all those GC array allocations
On Wednesday, 18 September 2013 at 13:39:29 UTC, bearophile wrote:
- Try to optionally accept the buffers from outside.
Does this look good to you?
/
auto ref betweenness(T = double, Graph)(ref Graph g, bool[]
ignore = null)
if (isFloating
Joseph Rushton Wakeling:
in the case of this code I think that stack vs. heap probably
isn't that important. If the data is small enough for stack
allocation, the calculation will be quick anyway.
How many times or how often do you need to call betweenness()? If
it's called only few times o
On Wednesday, 18 September 2013 at 15:17:25 UTC, Joseph Rushton
Wakeling wrote:
I think I did give std.array.Array a trial when trying to speed
up its performance, and I don't remember it making any
difference (if anything it may have slowed things down). But
I'll give it a second look and rep
On Wednesday, 18 September 2013 at 15:22:51 UTC, bearophile wrote:
Joseph Rushton Wakeling:
I haven't yet tried alloca or other manual memory management
-- I felt a bit resistant to this as I'd prefer to keep the
code simple and readable -- but I'll give that a go too just
to see how it goes.
Joseph Rushton Wakeling:
I haven't yet tried alloca or other manual memory management --
I felt a bit resistant to this as I'd prefer to keep the code
simple and readable -- but I'll give that a go too just to see
how it goes.
I'd like some stack-allocated variable-length array in D+Phobos,
On Wednesday, 18 September 2013 at 13:39:29 UTC, bearophile wrote:
Just for a test, try to allocate all those arrays in a
different way:
- First try a std.array.Array using the LDC2 compiler;
- Another thing to try is to allocate them on the stack using
core.stdc.stdlib.alloca:
auto p = cast(T
Joseph Rushton Wakeling:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
Some small improvements:
T[] betweenness(Graph, T = double)(ref Graph g, bool[] ignore =
null)
if (isGraph!Graph && isFloatingPoint!T)
{
enum T T0 = 0;
enum T T1 = 1;
auto centrality =
min
Hello all,
I thought I'd do a writeup of the process of implementing and
optimizing one of the graph metrics in Dgraph, starting from a
fairly straight copy of pseudo-code in a research paper all
through the various incremental tweaks that improve performance.
http://braingam.es/2013/09/betwe
18 matches
Mail list logo
