[erlang-questions] suitability of erlang

[Joe Armstrong]

On Wed, Oct 10, 2012 at 6:06 PM, Rustom Mody <rustompmody@REDACTED> wrote:
> On Wed, Oct 10, 2012 at 3:45 PM, Matthias Lang <matthias@REDACTED>
> wrote:
>>
>> 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

> http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/
> is a haskell implementers view of the terminology
> I wonder where erlang fits in on this
>
> Rusi
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>