<br><br><div class="gmail_quote">On Thu, Oct 11, 2012 at 12:00 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Oct 10, 2012 at 6:06 PM, Rustom Mody <<a href="mailto:rustompmody@gmail.com">rustompmody@gmail.com</a>> wrote:<br>
> On Wed, Oct 10, 2012 at 3:45 PM, Matthias Lang <<a href="mailto:matthias@corelatus.se">matthias@corelatus.se</a>><br>
> wrote:<br>
>><br>
>> On Wednesday, October 10, Rustom Mody wrote:<br>
><br>
><br>
>><br>
>> Another thing: you write "under severe time-crunch", but that could<br>
>> mean "we need to ship a product in a very short time" or it could mean<br>
>> "the data has to be processed in a very short time".<br>
>><br>
>> Matt<br>
><br>
><br>
> Well mainly the latter<br>
> But the former is also true. (When is it ever not :-))<br>
> My concern is that there is some desire to try out erlang which may be<br>
> fine... However I am wondering whether the difference between concurrency<br>
> and parallelism has not been appreciated.<br>
<br>
</div>Very true - I have given several lectures on this ... many people use the<br>
words concurrent and parallel as synonyms - but there is a real difference.<br>
<br>
In a nutshell - parallel has to do with real hardware than can do<br>
several things "at the same time"<br>
whereas concurrency is a software structuring abstraction which<br>
pretends that different<br>
parts of the software can run at the same time (if suitable hardware<br>
were available)<br>
<br>
Parallel has to do with hardware - on a single cpu you can write your programs<br>
using pmap (instead of map) and parBegin and parEnd  and it won't make<br>
any difference<br>
since the machine is still only doing one instruction at a time.<br>
<br>
It's only because machine are fast that we think they do several<br>
things in parallel -<br>
in the single CPU + time sharing case if we slowed the clock down we would see<br>
that no parallelism is involved - the CPU does one thing a time - even<br>
when executing<br>
concurrent programs :-)<br>
<br>
There are only a few real sources of true parallelism - multi-cores,<br>
what happens in the pipeline, and how data is fetched/stored<br>
<br>
Multicores do give you true parallelism, but you must be careful to<br>
about the granularity<br>
of computation - ie it should not be more work to shift the work to a<br>
remote CPU than do it<br>
locally. Pipeline messing is old for compiler writers. Data fetching<br>
and storing can be done in<br>
parallel, this needs a bit of thought.<br>
<br>
Parallel programs are inherently non portable - in the sense that they<br>
specifically depend<br>
upon details of the hardware.<br>
<br>
Concurrent programs are program written using a concurrency<br>
abstraction. In Erlang<br>
processes are the unti of concurrency - processes are pretty coarse-grain things<br>
ie they take a wee bit of effort to get going, so they actually map<br>
well onto multi-cores,<br>
even if you can detect parallelism in your program (easy in a pure FP,<br>
just evaluate<br>
all the arguments to a function in parallel) - it's pretty difficult<br>
(ie an open research problem)<br>
to map this onto the available hardware.<br>
<br>
Even if you know how long computations take, and you know what<br>
resources you have<br>
to solve the computations, then mapping the computations onto the<br>
resources involves<br>
solving the knapsack problem which is NP hard.<br>
<br>
It you write program in Erlang you at least have a head start over<br>
sequential code<br>
since the programmer has at least said (using processes) which<br>
activities should be run in parallel.<br>
Optimally scheduling these is NP hard - but non-optimal first on<br>
demand, best effort scheduling<br>
works pretty well for non-pathological code.<br>
<br>
My 10 c.<br>
<span class="HOEnZb"><font color="#888888"><br>
/Joe</font></span></blockquote><div><br>Thanks Joe for a detailed answer.<br><br>I have one more question that sits somewhere between parallelism and concurrency.<br>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.<br>
And at the heart of an event-driven system is usually an FSM.<br>Now I am particularly interested in the combined (regular-exp+FSM) approach that ragel provides: <a href="http://www.complang.org/ragel/">http://www.complang.org/ragel/</a><br>
<br>In particular, here is the use of ragel to write an http server: <a href="http://www.zedshaw.com/essays/ragel_state_charts.html">http://www.zedshaw.com/essays/ragel_state_charts.html</a><br><br>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?<br>
<br>Rusi<br>
</div></div><br><br>