hi all.
for example, i have a lisp program that was written in poor functional
style, i.e. without side-effect and with recursive functions. can this
program been paralleled automatically(by interpreter/compiler) or not?
thanks.
On Oct 3, 5:26 am, ············@gmail.com wrote:
> hi all.
> for example, i have a lisp program that was written in poor functional
> style, i.e. without side-effect and with recursive functions. can this
> program been paralleled automatically(by interpreter/compiler) or not?
There'a an argument that pure functional programs can easily be
parallelised. For instance if I have:
(+ (f ...) (g ...))
Then, if F and G are pure functions, clearly they can be executed in
parallel rather than sequentially.
In practice things are seldom this simple for the usual myriad of
reasons.
--tim
Tim Bradshaw wrote:
> On Oct 3, 5:26 am, ············@gmail.com wrote:
>
>>hi all.
>>for example, i have a lisp program that was written in poor functional
>>style, i.e. without side-effect and with recursive functions. can this
>>program been paralleled automatically(by interpreter/compiler) or not?
>
>
> There'a an argument that pure functional programs can easily be
> parallelised. For instance if I have:
>
> (+ (f ...) (g ...))
>
> Then, if F and G are pure functions, clearly they can be executed in
> parallel rather than sequentially.
>
> In practice things are seldom this simple for the usual myriad of
> reasons.
Do you think Cells would help?
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Oct 3, 2:23 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> On Oct 3, 5:26 am, ············@gmail.com wrote:
>
> > hi all.
> > for example, i have a lisp program that was written in poor functional
> > style, i.e. without side-effect and with recursive functions. can this
> > program been paralleled automatically(by interpreter/compiler) or not?
>
> There'a an argument that pure functional programs can easily be
> parallelised. For instance if I have:
>
> (+ (f ...) (g ...))
>
> Then, if F and G are pure functions, clearly they can be executed in
> parallel rather than sequentially.
>
> In practice things are seldom this simple for the usual myriad of
> reasons.
>
yeah, i know, but i asked about _automatic_ parallelisation. i.e. when
compiler/interpreter can do it for end-user itself. like in haskell
for example.
as i understood most of common lisp implementations(clisp, gcl) can't
do such thing.
On Oct 3, 1:06 pm, ············@gmail.com wrote:
>
> yeah, i know, but i asked about _automatic_ parallelisation. i.e. when
> compiler/interpreter can do it for end-user itself.
I misread, I think: sorry. I meant to imply that it's clearly
possible for a Lisp system to do this. I don't think many/any do
however. Not only does it depend on knowing that things are pure
which is harder than it looks, but it's also fairly hard to even know
when it's worth it given modern memory architectures.
--tim
············@gmail.com writes:
> yeah, i know, but i asked about _automatic_
> parallelisation. i.e. when compiler/interpreter can do it for
> end-user itself. like in haskell for example. as i understood most
> of common lisp implementations(clisp, gcl) can't do such thing.
No language that doesn't define it as permissible can, for various
reasons.
Languages must define when they can, might, must, might not, and must
not be parallel (or sequential). No language freely jumps between
these without potentially confusing its users since the user needs to
know when it's his right to assume the compiler will do something and
when it's his responsibility to do it himself.
Common Lisp evaluation-order is defined to be left-to-right sequential
evaluation (except where otherwise specified by a specific construct).
It's rather like "caller saves" vs "callee saves" register
conventions. Systems much choose. They can choose different things
in different places. But you can't just say it doesn't matter because
the whole point of the convention in the first place is to allow two
parties who have not been in active communication with each other to
do the right thing and have it snap together.
For example, to do this, Lisp would have to have no global state
and/or would have to be all compiled in a block so that the compiler
could tell no global state had been used. And even then I'm not sure
it would work unless you had a language so boring that it offered no
side effects at all.
Even something ss simple as I/O or random number generation or the
time of day can throw a wrinkle into this kind of analysis, since
these things need global state. (You might think a random number
generator wouldn't, but the whole reason these things have seeds is so
you can reproduce a computational run using the same pseudo-random
sequence. That's tricky to do in true parallelism.)
The flip side of "lisp can't do parallelism automatically (without
guidance from programmer)" is that "haskell can't do sequentialism
automatically (without guidance from programmer)", hence the stronger
need for monadic style or some other way of assuring things don't get
out of order.
On Oct 3, 5:59 pm, Kent M Pitman <······@nhplace.com> wrote:
> ············@gmail.com writes:
> > yeah, i know, but i asked about _automatic_
> > parallelisation. i.e. when compiler/interpreter can do it for
> > end-user itself. like in haskell for example. as i understood most
> > of common lisp implementations(clisp, gcl) can't do such thing.
>
> No language that doesn't define it as permissible can, for various
> reasons.
>
> Languages must define when they can, might, must, might not, and must
> not be parallel (or sequential). No language freely jumps between
> these without potentially confusing its users since the user needs to
> know when it's his right to assume the compiler will do something and
> when it's his responsibility to do it himself.
>
> Common Lisp evaluation-order is defined to be left-to-right sequential
> evaluation (except where otherwise specified by a specific construct).
>
> It's rather like "caller saves" vs "callee saves" register
> conventions. Systems much choose. They can choose different things
> in different places. But you can't just say it doesn't matter because
> the whole point of the convention in the first place is to allow two
> parties who have not been in active communication with each other to
> do the right thing and have it snap together.
>
> For example, to do this, Lisp would have to have no global state
> and/or would have to be all compiled in a block so that the compiler
> could tell no global state had been used. And even then I'm not sure
> it would work unless you had a language so boring that it offered no
> side effects at all.
>
> Even something ss simple as I/O or random number generation or the
> time of day can throw a wrinkle into this kind of analysis, since
> these things need global state. (You might think a random number
> generator wouldn't, but the whole reason these things have seeds is so
> you can reproduce a computational run using the same pseudo-random
> sequence. That's tricky to do in true parallelism.)
>
> The flip side of "lisp can't do parallelism automatically (without
> guidance from programmer)" is that "haskell can't do sequentialism
> automatically (without guidance from programmer)", hence the stronger
> need for monadic style or some other way of assuring things don't get
> out of order.
thanks for completely explanation.
Greetings!
GCL has si::p-let, si::p-and, and si::p-or primitives which force the
user to ensure that the calls are side-effect free. (At one point, I
thought the distinction between let and let* in lisp (and setq
vs. psetq) offered a conceptual basis for parallelism in the language,
but this is not true -- let bindings must be executed left to right.)
And there is an mpi binding that can e built in at compile time.
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
In article <························@g4g2000hsf.googlegroups.com>,
············@gmail.com wrote:
> hi all.
> for example, i have a lisp program that was written in poor functional
> style, i.e. without side-effect and with recursive functions. can this
> program been paralleled automatically(by interpreter/compiler) or not?
>
> thanks.
Depends. There has not been much use of this technique in
most Lisp environments. There was some research in that
direction - but that was years ago.
Parcel
http://portal.acm.org/citation.cfm?id=55364.55416
Miprac
http://citeseer.ist.psu.edu/harrison92programs.html
--
http://lispm.dyndns.org
On Oct 3, 2:47 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <························@g4g2000hsf.googlegroups.com>,
>
> ············@gmail.com wrote:
> > hi all.
> > for example, i have a lisp program that was written in poor functional
> > style, i.e. without side-effect and with recursive functions. can this
> > program been paralleled automatically(by interpreter/compiler) or not?
>
> > thanks.
>
> Depends. There has not been much use of this technique in
> most Lisp environments. There was some research in that
> direction - but that was years ago.
>
> Parcelhttp://portal.acm.org/citation.cfm?id=55364.55416
>
> Miprachttp://citeseer.ist.psu.edu/harrison92programs.html
>
> --http://lispm.dyndns.org
thanks a lot.