Is functional Language more fit for parallel programming?
Is it easier to figure out or abstract the DATA RELEVANCE between
instructions when we are using functional language?
Any suggestion?
Or just a brain storm about the possible solution on parallel
programming model.
From: Paul Tarvydas
Subject: Re: Is there some suggestions about the Parallel programming Model using LISP?
Date:
Message-ID: <gbiv9d$i7u$1@aioe.org>
·········@gmail.com wrote:
> Or just a brain storm about the possible solution on parallel
> programming model.
My leanings are summarized in the papers at www.visualframeworksinc.com.
pt
From: John Thingstad
Subject: Re: Is there some suggestions about the Parallel programming Model using LISP?
Date:
Message-ID: <op.uh3hwaqjut4oq5@pandora.alfanett.no>
P� Fri, 26 Sep 2008 17:22:22 +0200, skrev ·········@gmail.com
<·········@gmail.com>:
> Is functional Language more fit for parallel programming?
> Is it easier to figure out or abstract the DATA RELEVANCE between
> instructions when we are using functional language?
> Any suggestion?
> Or just a brain storm about the possible solution on parallel
> programming model.
There are many ideas about this. Some claim functional programming makes
parallelism simpler. I take that with a grain of salt. It seems parallel
functions is a bit to fine a mesh to utilize parallel processors
efficiently. Languages like Oz utilize data flow control and lightweight
threads instead. I would glance toward Oz or Erlang for some modern ideas
in parallel programming. Another approach is agent based programming.
Agents are typically large enough to be implemented as objects and can be
handled by DCOM or CORBA. You could read "Artificial Intelligence a Modern
Approach" by Peder Norvig (AIMA) of some other text on the subject.
--------------
John Thingstad
On Sep 26, 12:42 pm, "John Thingstad" <·······@online.no> wrote:
> På Fri, 26 Sep 2008 17:22:22 +0200, skrev ·········@gmail.com
> <·········@gmail.com>:
> > Is functional Language more fit for parallel programming?
>
> There are many ideas about this. Some claim functional programming makes
> parallelism simpler. I take that with a grain of salt. It seems parallel
> functions is a bit to fine a mesh to utilize parallel processors
> efficiently.
Yes, I always wondered about this. At least in the case of an eager
strict language like Scheme, parallelization of operations like, say,
evaluation of arguments to functions, would not lead to highly
parallelized code, since functions being called would have to wait for
their arguments being completely evaluated before proceeding. In the
case of non-strict languages like Haskell, I think the lazy mechanics
have an advantage here...
namekuseijin <············@gmail.com> writes:
>On Sep 26, 12:42=A0pm, "John Thingstad" <·······@online.no> wrote:
>> P=E5 Fri, 26 Sep 2008 17:22:22 +0200, skrev ·········@gmail.com =A0
>> <·········@gmail.com>:
>> > Is functional Language more fit for parallel programming?
>>
>> There are many ideas about this. Some claim functional programming makes =
>=A0
>> parallelism simpler. I take that with a grain of salt. It seems parallel =
>=A0
>> functions is a bit to fine a mesh to utilize parallel processors =A0
>> efficiently.
>Yes, I always wondered about this. At least in the case of an eager
>strict language like Scheme, parallelization of operations like, say,
>evaluation of arguments to functions, would not lead to highly
>parallelized code, since functions being called would have to wait for
>their arguments being completely evaluated before proceeding. In the
>case of non-strict languages like Haskell, I think the lazy mechanics
>have an advantage here...
It is difficult to do automatic parrallelization on things like you
mention. I'd say that it's easier to multi-thread a referentially
transparent program, which makes functional programming enticing, but
you still have to figure out when it is a good time to parallel
procedures.
Aaron Hsu
--
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) +++++++++++++++
Email: <·······@sacrideo.us> | WWW: <http://www.sacrideo.us>
Scheme Programming is subtle; subtlety can be hard.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A concurrent implementation of map-reduce could help you. I'm not sure
if there's an open source version in CL, but it shouldn't be too hard
to implement.
On Sep 27, 1:11 pm, Ali <·············@gmail.com> wrote:
> A concurrent implementation of map-reduce could help you. I'm not sure
> if there's an open source version in CL, but it shouldn't be too hard
> to implement.
It's actually a surprising pain in the butt. There are a lot of little
details that depend on your deployment environment.
From: Kaz Kylheku
Subject: Re: Is there some suggestions about the Parallel programming Model using LISP?
Date:
Message-ID: <20080926132331.911@gmail.com>
On 2008-09-26, ·········@gmail.com <·········@gmail.com> wrote:
> Is functional Language more fit for parallel programming?
More fit than what? What kind of parallel programming?
> Is it easier to figure out or abstract the DATA RELEVANCE between
> instructions when we are using functional language?
Functional programs do not modify data. They change the machine state by
constructing new objects (which may use existing ones as constituents).
If data isn't modified, data race conditions cannot happen. So, in functional
programming, an entire class of parallel programming bugs disappears.
Since functional programs do not modify data, they can have loose evaluation
orders. Evaluation order matters when evaluation is interleaved with side
effects, such as modifying data or performing I/O. When an expression is known
to be free of side effects, its evaluation can be safely parallelized.
From: John Thingstad
Subject: Re: Is there some suggestions about the Parallel programming Model using LISP?
Date:
Message-ID: <op.uh3x9ue3ut4oq5@pandora.alfanett.no>
P� Fri, 26 Sep 2008 22:33:07 +0200, skrev Kaz Kylheku <········@gmail.com>:
> On 2008-09-26, ·········@gmail.com <·········@gmail.com> wrote:
>> Is functional Language more fit for parallel programming?
>
> More fit than what? What kind of parallel programming?
>
>> Is it easier to figure out or abstract the DATA RELEVANCE between
>> instructions when we are using functional language?
>
> Functional programs do not modify data. They change the machine state by
> constructing new objects (which may use existing ones as constituents).
> If data isn't modified, data race conditions cannot happen. So, in
> functional
> programming, an entire class of parallel programming bugs disappears.
>
> Since functional programs do not modify data, they can have loose
> evaluation
> orders. Evaluation order matters when evaluation is interleaved with side
> effects, such as modifying data or performing I/O. When an expression
> is known
> to be free of side effects, its evaluation can be safely parallelized.
All important points when it comes to verifying program correctness. But
what they don't dictate is what should be done in parallel. For sure a
functional approach helps, but it is not a substitute to higher order
constructs to control the division in work-flow. Besides it is not a
Panacea when dealing with processing. Functions depend on other functions
completing. Thus the chance of deadlock still exists. Oz contains
additional structure to deal explicitly with parallelism which Haskell
lacks. Data-flow threads focus explicitly on the flow of data letting a
programmer tell the program where it is OK to run on a separate processor.
High level tool for supporting running on several machines handling with
means of communication like mirroring of data or direct access.
--------------
John Thingstad