> >> On Wednesday, October 10, Rustom Mody wrote:

> >> Another thing: you write "under severe time-crunch", but that could
> >> mean "we need to ship a product in a very short time" or it could mean
> >> "the data has to be processed in a very short time".

> >> Matt

> > Well mainly the latter
> > But the former is also true. (When is it ever not :-))
> > My concern is that there is some desire to try out erlang which may be
> > fine... However I am wondering whether the difference between concurrency
> > and parallelism has not been appreciated.

> Very true - I have given several lectures on this ... many people use the
> words concurrent and parallel as synonyms - but there is a real difference.

> In a nutshell - parallel has to do with real hardware than can do
> several things "at the same time"
> whereas concurrency is a software structuring abstraction which
> pretends that different
> parts of the software can run at the same time (if suitable hardware
> were available)

> Parallel has to do with hardware - on a single cpu you can write your
> programs
> using pmap (instead of map) and parBegin and parEnd  and it won't make
> any difference
> since the machine is still only doing one instruction at a time.

> It's only because machine are fast that we think they do several
> things in parallel -
> in the single CPU + time sharing case if we slowed the clock down we would
> see
> that no parallelism is involved - the CPU does one thing a time - even
> when executing
> concurrent programs :-)

> There are only a few real sources of true parallelism - multi-cores,
> what happens in the pipeline, and how data is fetched/stored

> Multicores do give you true parallelism, but you must be careful to
> about the granularity
> of computation - ie it should not be more work to shift the work to a
> remote CPU than do it
> locally. Pipeline messing is old for compiler writers. Data fetching
> and storing can be done in
> parallel, this needs a bit of thought.

> Parallel programs are inherently non portable - in the sense that they
> specifically depend
> upon details of the hardware.

> Concurrent programs are program written using a concurrency
> abstraction. In Erlang
> processes are the unti of concurrency - processes are pretty coarse-grain
> things
> ie they take a wee bit of effort to get going, so they actually map
> well onto multi-cores,
> even if you can detect parallelism in your program (easy in a pure FP,
> just evaluate
> all the arguments to a function in parallel) - it's pretty difficult
> (ie an open research problem)
> to map this onto the available hardware.

> Even if you know how long computations take, and you know what
> resources you have
> to solve the computations, then mapping the computations onto the
> resources involves
> solving the knapsack problem which is NP hard.

> It you write program in Erlang you at least have a head start over
> sequential code
> since the programmer has at least said (using processes) which
> activities should be run in parallel.
> Optimally scheduling these is NP hard - but non-optimal first on
> demand, best effort scheduling
> works pretty well for non-pathological code.

> My 10 c.

> /Joe