[erlang-questions] Concurrency-related optimizations

[Jacob Lee]

On Tue, Jan 29, 2008 at 4:16 AM, Thomas Lindgren
<thomasl_erlang@REDACTED> wrote:
>
>  --- Jacob Lee <jelee2@REDACTED> wrote:
>
>  > My question for the general
>  > Erlang community is:
>  > are there any optimizations that have been
>  > considered or suggested for
>  > Erlang but not yet implemented? My focus is on
>  > concurrency-related
>  > optimization: e.g., those related to scheduling or
>  > message passing.
>
>  Some input from actors researchers sounds great.
>
>  Apart from the 'Hippo' paper mentioned before, I seem
>  to remember hearing about some experiments at Ericsson
>  CSlab to schedule the receiver right after the sender
>  when a message was sent. There was no significant
>  performance benefit at that time. (Though I think that
>  was done for the far slower JAM virtual machine.)
>

Chapter 6 from "Efficient Implementation of Concurrent Programming
Languages"  - http://citeseer.ist.psu.edu/705309.html - contains
information from the Hippo project and also talks about rescheduling
send. It seems to only have benchmarks for all of HiPE, though, not
specific optimizations.

>  The hybrid and shared heap VMs reduce message passing
>  costs by avoiding copying. Gains for real apps seem
>  inconclusive so far.
>
>  As mentioned by another poster, receive statements can
>  perform badly. This has been documented, um, somewhere
>  on this mailing list, I seem to recall. (Sorry.)
>
>  There hasn't been much published about scheduling. The
>  old-timers usually just shudder and change the subject
>  when anything beyond the existing heuristic scheduler
>  with high/medium/low priorities is mentioned :-)
>  Actually, there seems to be some OTP experimentation
>  behind the scenes (process prio based on message queue
>  length?), but little has been published.
>

That would indeed be interesting to look at. The challenge is that any
alternate implementations must be as fair as the current scheduler --
or at least fair enough to avoid priority inversion, starvation, etc.
(I'm not sure if Erlang has any requirements here more formal than
"every process must get scheduled eventually" and "existing programs
should not break"). It might tie in to fiddling with the message
queue, as well.

>  While Erlang processes are pretty lightweight, they
>  still are much heavier than the dataflow-style
>  'actors' we looked at in the 80s and 90s. Maybe
>  something could be done there.
>
>  Best,
>  Thomas
>

It's an interesting comparison to make. One theoretical idea from the
actor model is to have "actors all the way down", though in the real
world this is obviously curtailed (e.g. using actual integers instead
of actors that reply with a constant... etc.). Many common patterns in
this model involve spawning anonymous actors all over the place to
maximize concurrency. For example, there's a join continuation
transformation -- http://osl.cs.uiuc.edu/docs/hpc96/hipc-kim.pdf --
that allows RPC to be written in the intuitive manner (as if it were a
blocking call) but allows computations not dependent on the result of
the RPC to continue in parallel. The constraint in doing all this in
Erlang is that this type of transformation might break the original
program in subtle ways.

Thanks for the suggestions!

-- 
Jacob Lee
artdent@REDACTED