automatic concurrency

[Mark Volkmann]

One of the stated benefits of functional programming I've seen is that
the compiler of a functional language can analyze code and determine
statements within a function 
that can safely be run concurrently. As
far as I know Clojure doesn't yet do this. Correct?

Which functional programming languages, if any, do this?

--
R. Mark Volkmann
Object Computing, Inc.

[Brian Will]

Clojure doesn't start any threads you don't tell it to.

In Haskell, there's a strict compile-time distinction between pure
functions and impure functions, so Haskell always knows which
functions can be run concurrently without issue. Actually running
stuff concurrently without explicit direction from the programmer,
however, is another matter. The implementations of Haskell that do
this are experimental and not widely used.

http://en.wikipedia.org/wiki/Automatic_parallelization

--Brian Will

[Mark H.]

On Jan 3, 12:20 pm, "Mark Volkmann" <r.mark.volkm...@gmail.com> wrote:

> One of the stated benefits of functional programming I've seen is that
> the compiler of a functional language can analyze code and determine
> statements within a function 
that can safely be run concurrently. As
> far as I know Clojure doesn't yet do this. Correct?

Clojure does not automatically exploit thread parallelism for
performance. However, the JVM implementation quite probably exploits
instruction-level parallelism and may also have a parallel and/or
concurrent garbage collector. (Parallel CG means exploiting
parallelism to make the GC itself run faster; concurrent GC means a
garbage collection doesn't "stop the world.")

> Which functional programming languages, if any, do this?

SISAL and NESL are the two most prominent examples in my mind. The
reason why not a lot of functional programming languages did this was
because previously, "parallel" was something only HPC folks worried
about, and HPC folks didn't want to switch to functional languages for
various reasons, partly cultural and partly practical. (SISAL was one
attempt to get them to switch and it didn't work, despite its compiler
being fairly successful at automatic parallelization.)

Now your laptop is parallel because of the Power Wall and ordinary
mortal coders are being asked to write parallel code. (The best HPC
coders are the sort that can find bottlenecks by passing their hand
over the CPU die and grokking where the bits go.) It's enough of a
paradigm shift and the number of affected programmers is large enough
that people are considering new programming language solutions.

Remember that "parallel" and "concurrent" are two different things.
"Concurrent" is something you deal with all the time if you are
writing GUI apps: there are different threads and they interact in
some possibly unpredictable way. You can have concurrency on a single-
core machine. "Parallel" means multiple CPUs working together for
_performance_, i.e., to run faster. Clojure has a lot of tools to
solve concurrency problems. I think of it as a language designed for
that goal. There are also tools in Clojure (like pmap) to exploit
parallelism, but the concurrency tools are more developed.

mfh

[Mark H.]

On Jan 3, 2:08 pm, Brian Will <brian.thomas.w...@gmail.com> wrote:
> http://en.wikipedia.org/wiki/Automatic_parallelization

The article looks out-of-date and inaccurate, alas...

mfh

[Brian Will]

> Remember that "parallel" and "concurrent" are two different things.
> "Concurrent" is something you deal with all the time if you are
> writing GUI apps: there are different threads and they interact in
> some possibly unpredictable way. You can have concurrency on a single-
> core machine. "Parallel" means multiple CPUs working together for
> _performance_, i.e., to run faster.

I'm not sure this distinction is widely accepted. The term "parallel",
as I've heard it used, means simultaneous computation, which is one
kind of concurrency.

It's also worth pointing out that event-drive concurrency, e.g. GUI
stuff, is really just about optimization too. If we had an infinitely
fast machine, we'd probably simply always do everything interactive/
real-time in a game loop. (We'd still probably write event-driven
code, but it would all involve just one thread, much like Javascript
events work in the browser now.)

> The article looks out-of-date and inaccurate, alas...

Yeah, I got this impression as well. I coulda sworn it was better the
last time I looked at it.

--Brian Will

[Mark H.]

On Jan 3, 9:53 pm, Brian Will <brian.thomas.w...@gmail.com> wrote:
> > Remember that "parallel" and "concurrent" are two different things.
> > "Concurrent" is something you deal with all the time if you are
> > writing GUI apps:  there are different threads and they interact in
> > some possibly unpredictable way.  You can have concurrency on a single-
> > core machine.  "Parallel" means multiple CPUs working together for
> > _performance_, i.e., to run faster.
>
> I'm not sure this distinction is widely accepted. The term "parallel",
> as I've heard it used, means simultaneous computation, which is one
> kind of concurrency.

Hm, we could use some Venn diagrams... ;-) I shouldn't have drawn
such a sharp distinction perhaps.

> It's also worth pointing out that event-drive concurrency, e.g. GUI
> stuff, is really just about optimization too.

That's true, but there the model of computation is based on events,
which happen asynchronously. "Parallel" computation in the sense I
put it can be completely synchronous from the programmer's
perspective, and some parallel libraries even implement it this way
(e.g., OpenMP, unless you tell it otherwise). Of course the models
and implementations are fluid and chosen to fit the applications. My
main point was to answer the OP's complaint that Clojure didn't solve
the "turn arbitrary sequential code into parallel code with perfect
speedup" magic compiler problem ;-)

mfh

[Konrad Hinsen]

On 03.01.2009, at 21:20, Mark Volkmann wrote:

> One of the stated benefits of functional programming I've seen is that
> the compiler of a functional language can analyze code and determine
> statements within a function
> that can safely be run concurrently. As
> far as I know Clojure doesn't yet do this. Correct?

Yes.

> Which functional programming languages, if any, do this?

None of the well-known ones. Perhaps none at all.

While it is true that *pure* functional programs (Clojure programs
are not guaranteed to be purely functional) can be analyzed by a
compiler to detect what can safely be executed in parallel, that is
only half the story. The other important step is figuring out what to
execute in parallel in order to gain speed, and that problem is still
unsolved.

Still, functional programming is a big help in manual
parallelization, as you don't have to worry about breaking your code.
You just have to work for gaining speed.

Konrad.