std.parallelism changes done

dsimcha dsimcha at yahoo.com
Thu Mar 24 10:04:28 PDT 2011


== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> dsimcha:
> > I tried to keep it as consistent as possible with std.algorithm.
> OK. Then the question is why std.algorithm uses normal strings instead of q{} ones.

I personally think "" strings look nicer for simple cases like "a + b".  At any
rate, this is a bikeshed issue.

> And regarding consistency with std.algorithm, a more important factor is that
std.algorithm.map is lazy, while you have a eager map, and the lazy version has
lazy in the name, so the names are kind of opposite of std.algorithm.

Hmm, you do have a point there.  Two reasons:

1.  map() was there first and at the time I didn't feel like renaming it.

2.  I think map() is much more frequently useful than lazyMap() and name verbosity
should be inversely proportional to usage frequency.  (Which is why I really need
help thinking of a better name than executeInNewThread().)

I'm not sure whether I want to change this.  Input from the rest of the community
would be useful as long as it doesn't end up going off onto some wild tangent and
starting Bikeshed War III.

> > Unfortunately I don't have access to this kind of hardware except at work.
> Maybe some other person in this group has access to a 8 core CPU and is willing
to take some numbers, to create few little graphs.

I can kinda see Andrei's point about adding a few benchmarks just to give a rough
idea of the level of fine-grainedness this library is capable of and how to get
it, but these requests are exactly what I was afraid of when I put them in.  I
really don't think rigorous, detailed benchmarks have any place in API
documentation.  The purpose of API documentation is for people to figure out what
the library does and how to use it, not to sell a product or precisely quantify
its performance.

Next people will be asking for standard deviations, error bars, P-values,
confidence intervals, regression models of performance vs. cores and basically
things that dstats is good for, or for me to port their favorite non-trivial
benchmark from their favorite non-D language.


More information about the Digitalmars-d mailing list