David,
On Thu, 2011-02-03 at 20:56 -0500, dsimcha wrote:
Ok, I finally got around to tackling most of this. See individual
replies below.
Any chance you can put this package in a separate DVCS repository (I'll
assume Git given the way the rest of D is going) so that updates can be
picked up
I could move it over to github, though I'll wait to do that until I get
a little more comfortable with Git. I had never used Git before until
Phobos switched to it. In the mean time, to remind, the code is at:
On Fri, 2011-02-04 at 08:09 -0500, dsimcha wrote:
I could move it over to github, though I'll wait to do that until I get
a little more comfortable with Git. I had never used Git before until
Phobos switched to it. In the mean time, to remind, the code is at:
svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
works for me
On 02/04/2011 11:28 AM, Russel Winder wrote:
On Fri, 2011-02-04 at 08:09 -0500, dsimcha wrote:
I could move it over to github, though I'll wait to do that until I get
a little more comfortable with Git. I had
On Fri, 04 Feb 2011 17:28:25 +
Russel Winder rus...@russel.org.uk wrote:
PS I strongly recommend you find ways of learning Git, although I
prefer Mercurial and Bazaar to Git, any of these three make
developing a pleasure compared to using Subversion. Once you get
into DVCS there is no
On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
works for me
[ . . . ]
Phobos switched to it. In the mean time, to remind, the code is at:
dsimcha napisał:
I could move it over to github, though I'll wait to do that until I get
a little more comfortable with Git. I had never used Git before until
Phobos switched to it. In the mean time, to remind, the code is at:
Russel Winder wrote:
On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
works for me
[ . . . ]
Phobos switched to it. In the mean time, to remind, the code is at:
== Quote from Tomek Sowiński (j...@ask.me)'s article
Please run the docs through a spell-checker, there are a few typos:
asyncBuf() - for ecample
stop() - waitied
lazyMap() - Parameters;
But I think it's good overall. These primitives are in demand.
--
Tomek
I will certainly tie up all of
On Fri, 2011-02-04 at 23:06 +0100, Jérôme M. Berger wrote:
Russel Winder wrote:
On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
works for me
[ . . . ]
Phobos switched to it. In the mean time, to remind,
Ok, I finally got around to tackling most of this. See individual
replies below.
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
* parallel is templated on range, but not on operation. Does this affect
speed for brief operations (such as the one given in the example,
squares[i] = i * i)? I wonder if using an alias wouldn't be more
appropriate. Some performance numbers would
Here's my results:
Parallel Foreach: 29.6365
Map: 23.1849
Serial: 32.9265
This is with -release -inline -O -noboundscheck
I'm on a quad-core btw.
On Sun, 02 Jan 2011 11:00:36 -0600, Andrei Alexandrescu wrote:
On 1/2/11 10:39 AM, dsimcha wrote:
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/
Andrei:
Overall it looks nice enough.
* I think it does make sense to evaluate a parallel map lazily by using
a finite buffer. Generally map looks the most promising so it may be
worth investing some more work in it to make it smart lazy.
I agree.
Some more notes:
Later a parallel max()
One more note: how are performances? Are benchmarks available? (I even suggest
to add some benchmarks to the std.parallelism module unit tests).
Bye,
bearophile
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
Documentation:
http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html
Here are a few
On 1/2/11 10:39 AM, dsimcha wrote:
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
Documentation:
Andrei Alexandrescu Wrote:
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
Documentation:
* why runCallable()? There's no runUncallable().
Does this even need to be public? It looks
dsimcha:
Andrei:
* I think it does make sense to evaluate a parallel map lazily by using
a finite buffer. Generally map looks the most promising so it may be
worth investing some more work in it to make it smart lazy.
Can you elaborate on this? I'm not sure what you're suggesting.
I
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 1/2/11 10:39 AM, dsimcha wrote:
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
* parallel is templated on range, but not on operation. Does this affect
speed for brief operations (such as the one given in the
I think David Simcha's library is close to reviewable form. Code:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
Documentation:
http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html
Here are a few comments:
* parallel is templated on range, but not on
22 matches
Mail list logo
