Prev: (apply #'concatenate 'list list)
Next: cliki kinda sucks, and this group has too many sneaker ads
From: Pascal Costanza on 11 Dec 2009 07:19
On 11/12/2009 13:04, Nicolas Neuss wrote:
> Pascal Costanza<pc(a)p-cos.net> writes:
>
>> [Parallel programming is actually starting to look good for Common
>> Lisp...]
>
> Apropos: Which direction of development did you have in mind?

Armed Bear CL, Clozure CL, Corman CL, ECL, SCL, and SBCL support native
threads. Support for synchronization features varies, though (which are
at least as important).

Allegro CL and LispWorks are currently working on SMP support. From what
I can see so far, this looks pretty good.

All you need at the low level is some form of native threads plus some
good synchronization data structures. (For example, I like LispWorks
mailboxes a lot, which are already in 5.x, but there are also other good
forms of synchronization.)

On top of such low-level features, you can build more interesting
things. I have already implemented a form of a parallel mapcar. It's not
mature enough yet, but it wasn't that much hard work either. Something
like Fortress's map/reduce in a Lisp setting would be cool. Then you
would have covered data parallelism pretty well. (Data parallelism is
more powerful than many people seem to think.)

For task parallelism, I think we have to live with locks and
compare-and-swap primitives. STM is overrated and too slow.

CL-MPI also looks interesting.

Just a rough overview...


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza on 11 Dec 2009 07:22
On 11/12/2009 13:19, Pascal Costanza wrote:
> On 11/12/2009 13:04, Nicolas Neuss wrote:
>> Pascal Costanza<pc(a)p-cos.net> writes:
>>
>>> [Parallel programming is actually starting to look good for Common
>>> Lisp...]
>>
>> Apropos: Which direction of development did you have in mind?
>
> Armed Bear CL, Clozure CL, Corman CL, ECL, SCL, and SBCL support native
> threads. Support for synchronization features varies, though (which are
> at least as important).
>
> Allegro CL and LispWorks are currently working on SMP support. From what
> I can see so far, this looks pretty good.
>
> All you need at the low level is some form of native threads plus some
> good synchronization data structures. (For example, I like LispWorks
> mailboxes a lot, which are already in 5.x, but there are also other good
> forms of synchronization.)
>
> On top of such low-level features, you can build more interesting
> things. I have already implemented a form of a parallel mapcar. It's not
> mature enough yet, but it wasn't that much hard work either. Something
> like Fortress's map/reduce in a Lisp setting would be cool. Then you
> would have covered data parallelism pretty well. (Data parallelism is
> more powerful than many people seem to think.)
>
> For task parallelism, I think we have to live with locks and
> compare-and-swap primitives. STM is overrated and too slow.
>
> CL-MPI also looks interesting.
>
> Just a rough overview...

I forgot to mention what's going on in the Scheme community. There is
interesting stuff going on there as well. Check comp.lang.scheme, or so...


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Nicolas Neuss on 12 Dec 2009 11:28
Pascal Costanza <pc(a)p-cos.net> writes:

> On 11/12/2009 13:04, Nicolas Neuss wrote:
>> Pascal Costanza<pc(a)p-cos.net> writes:
>>
>>> [Parallel programming is actually starting to look good for Common
>>> Lisp...]
>>
>> Apropos: Which direction of development did you have in mind?
>
> Armed Bear CL, Clozure CL, Corman CL, ECL, SCL, and SBCL support native
> threads. Support for synchronization features varies, though (which are at
> least as important).
>
> Allegro CL and LispWorks are currently working on SMP support. From what I
> can see so far, this looks pretty good.

Yes, but there is one caveat in that I am not sure about how far
multithreading goes in all these implementations. Some time ago, I
tried multithread parallelization of a routine which should be
parallelizable very well (finite element assembly) but got rather
disappointing results. I really have to examine better what is the
problem in my case, but "good" native thread support could mean that
concrrent hash-table writing should be possible or maybe even that GC
should be parallel at least for most recent generations.

[If Duane or someone else from Franz should read this: How is the state
of Allegro SMP/Linux?]

> All you need at the low level is some form of native threads plus some
> good synchronization data structures. (For example, I like LispWorks
> mailboxes a lot, which are already in 5.x, but there are also other
> good forms of synchronization.)
>
> On top of such low-level features, you can build more interesting
> things. I have already implemented a form of a parallel mapcar. It's
> not mature enough yet, but it wasn't that much hard work
> either. Something like Fortress's map/reduce in a Lisp setting would
> be cool. Then you would have covered data parallelism pretty
> well. (Data parallelism is more powerful than many people seem to
> think.)

I am thinking more in the direction of Oz parallelism (mentioned by
George Neuner already), which means IIUC delaying forms and evaluating
them in parallel threads. And I think that here is an important link to
dataflow programming like in Cells. For example, I have experimented
(i.e. measured speedup) with something I have called "parcells" which I
can use like this

(let* ((c1 (parcell () (calculate-local-matrix-slowly 1)))
(c2 (parcell () (calculate-local-matrix-slowly 2)))
(c3 (parcell ((c1 c1) (c2 c2))
(+ c1 c2))))
(value c3))

[I am not yet satisfied with this interface, but I think that something
like this might be an immediate application of a multithreaded "Cells"
and I would very much like to use it. Maybe one could even think about
compiling straightforward code automatically to such networks of cells,
which Oz does.]

> For task parallelism, I think we have to live with locks and
> compare-and-swap primitives. STM is overrated and too slow.

Hmm, possibly - I remember your long discussion with Rich Hickey. But I
would not object to having one tool more.

> CL-MPI also looks interesting.

And probably also CL-MUPROC should be mentioned.

> Just a rough overview...
>
> Pascal

OK, but I do not see anything yet which would let me parallelize my code
easily. At the moment, I have the impression that in the direction of
dataflow programming/parallelizations could lie some gains for my type
of application (and probably some good computer science articles as
well - although I do not intend to write them:-).

Nicolas

From: Duane Rettig on 13 Dec 2009 02:38
On Dec 12, 8:28 am, Nicolas Neuss <lastn...(a)math.uni-karlsruhe.de>
wrote:
>
> [If Duane or someone else from Franz should read this: How is the state
> of Allegro SMP/Linux?]

Progressing...

Duane
From: Slobodan Blazeski on 14 Dec 2009 05:29
On Dec 11, 1:22 pm, Pascal Costanza <p...(a)p-cos.net> wrote:
> On 11/12/2009 13:19, Pascal Costanza wrote:
>
>
>
> > On 11/12/2009 13:04, Nicolas Neuss wrote:
> >> Pascal Costanza<p...(a)p-cos.net> writes:
>
> >>> [Parallel programming is actually starting to look good for Common
> >>> Lisp...]
>
> >> Apropos: Which direction of development did you have in mind?
>
> > Armed Bear CL, Clozure CL, Corman CL, ECL, SCL, and SBCL support native
> > threads. Support for synchronization features varies, though (which are
> > at least as important).
>
> > Allegro CL and LispWorks are currently working on SMP support. From what
> > I can see so far, this looks pretty good.
>
> > All you need at the low level is some form of native threads plus some
> > good synchronization data structures. (For example, I like LispWorks
> > mailboxes a lot, which are already in 5.x, but there are also other good
> > forms of synchronization.)
>
> > On top of such low-level features, you can build more interesting
> > things. I have already implemented a form of a parallel mapcar. It's not
> > mature enough yet, but it wasn't that much hard work either. Something
> > like Fortress's map/reduce in a Lisp setting would be cool. Then you
> > would have covered data parallelism pretty well. (Data parallelism is
> > more powerful than many people seem to think.)
>
> > For task parallelism, I think we have to live with locks and
> > compare-and-swap primitives. STM is overrated and too slow.
>
> > CL-MPI also looks interesting.
>
> > Just a rough overview...
>
> I forgot to mention what's going on in the Scheme community. There is
> interesting stuff going on there as well. Check comp.lang.scheme, or so....
Plt recently announced smp via futures http://pre.plt-scheme.org/docs/html/futures/
too bad gambit doesn't work on windows and lacks smp its thread system
is really insane.

Bobi
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/

 | 
Pages: 1
Prev: (apply #'concatenate 'list list)
Next: cliki kinda sucks, and this group has too many sneaker ads