Andrei, PLEASE stop hitting reply all. Also,
please ignore the private message I sent you and read this one
instead, as I've included a reply to one more point in this one.
On 8/27/2010 1:20 AM, Andrei Alexandrescu wrote:
more geared toward concurrency (i.e.
making stuff appear to be happening
simultaneously, useful for things like GUIs and servers) rather
than
parallelism (i.e. the use of multiple CPU cores to increase
throughput,
useful for things like scientific computing and video
encoding). It
seems fairly difficult (though I haven't tried yet) to write
code that's
designed for pull-out-all-stops maximal performance on a
multicore
machine, especially since immutability is somewhat of a straight
jacket. I find implicit sharing and the use of small
synchronized
blocks or atomic ops to be very useful in writing parallel
programs.
2. From reading the description of std.concurrency in TDPL it
seemed
You are correct on all counts. D's current concurrency mechanisms
are not geared towards parallel SIMD-style programming.
I assume you meant SMP parallelism, not SIMD? ParallelFuture is
about SMP parallelism, not SIMD. SIMD == things like SSE
instructions.
4. I've been eating my own dogfood for
awhile on my ParallelFuture
library. (http://cis.jhu.edu/~dsimcha/parallelFuture.html;
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d)
It's geared toward throughput-oriented parallelism on multicore
machines, not concurrency for GUIs, servers, etc. and is higher
level
than std.concurrency. Is there any interest in including
something like
this in Phobos? If so, would we try to make it fit into the
explicit-sharing-only model, or treat it as an alternative
method of
multithreading geared towards pull-out-all-stops parallelism on
multicore computers?
There is interest. I think we should at best find the
language/library primitives necessary for making it work, and then
provide the primitives AND adopt your library into Phobos. That
way people can use your abstraction mechanisms and use their own.
Can you elaborate on this? Other than the atomics stuff that you
mention below, what lower level primitives do you think need to be
exposed? IMHO tasks, parallel map and reduce and parallel foreach are
the most basic primitives of this library. Except the atomics
stuff, basically all the lower level stuff it uses (condition
variables, etc) is straight out of Phobos/druntime.
I see you have some CAS instructions. Sean, I think it's a good
time to collaborate with David to put them into druntime or
std.concurrency.
Yeah, D needs a real atomics library. core.atomic is a good start,
but I won't use it until it can efficiently do things like
atomic increment.
Andrei
|
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
