[erlang-questions] suitability of erlang

[Rustom Mody]

On Thu, Oct 11, 2012 at 12:00 AM, Joe Armstrong <erlang@REDACTED> wrote:

> 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


Thanks Joe for a detailed answer.

I have one more question that sits somewhere between parallelism and
concurrency.
In the 'normal' world (ie C++, Java, Python) there is a general
recommendation that converting a threaded solution to an event-driven
solution usually speeds up the program and removes hard-to-find bugs.
And at the heart of an event-driven system is usually an FSM.
Now I am particularly interested in the combined (regular-exp+FSM) approach
that ragel provides: http://www.complang.org/ragel/

In particular, here is the use of ragel to write an http server:
http://www.zedshaw.com/essays/ragel_state_charts.html

Now since ragel is more or less language agnostic -- it has backends for
generating C, C++, Java, Ruby etc -- would an Erlang backend for ragel make
sense?

Rusi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121011/de17ea42/attachment.htm>