[Haskell-cafe] Re: Python's big challenges, Haskell's big advantages?

Aaron Denney wnoise at ofb.net
Wed Sep 17 17:20:29 EDT 2008


On 2008-09-17, Jonathan Cast <jonathanccast at fastmail.fm> wrote:
>> In my mind pooling vs new-creation is only relevant to process vs
>> thread in the performance aspects.
>
> Say what?  This discussion is entirely about performance --- does
> CPython actually have the ability to scale concurrent programs to
> multiple processors?  The only reason you would ever want to do that is
> for performance.

I entered the discussion as which model is a workaround for the other --
someone said processes were a workaround for the lack of good threading
in e.g. standard CPython.  I replied that most languages thread support can be
seen as a workaround for the poor performance of communicating processes.
(creation in particular is usually cited, but that cost can often be reduced
by process pools, context switching costs, alas, is harder.)

> Kernel threads /are/ expensive.  Which is why all the cool kids use
> user-space threads.

Often muxed on top of kernel threads, because user-threads can't use
multiple CPUs at once.

>> The central aspect in my mind is a default share-everything, or
>> default share-nothing.
>
> I really don't think you understand Concurrent Haskell, then.  (Or
> Concurrent ML, or stackless Python, or libthread, or any other CSP-based
> set-up).

Or Erlang, Occam, or heck, even jcsp.  Because I'm coming at this from a
slightly different perspective and place a different emphasis on things
you think I don't understand?  No, trust me, I do understand them[1],
and think CSP and actor models (the differences in nondeterminism is a
minor detail that doesn't much matter here) are extremely nice ways of
implementing parallel systems.

These are, in fact, process models.  They are implemented on top of thread models,
but that's a performance hack.  And while putting this model on top
restores much of the programming sanity, in languages with mutable
variables and references that can be passed, you still need a fair
bit of discipline to keep that sanity.  There, the implementation detail
of thread, rather than process allows and even encourages shortcuts that
violate the process model.  In languages that are immutable, taking
advantage of the shared memory space really can gain efficiency without
any noticeably downside.

[1] I used to work for a company designing and modeling CSP-based
hardware designs.  In my spare time I started writing a compiler from
our HDL to Concurrent Haskell, but abandoned it when I left for
grad school.

-- 
Aaron Denney
-><-



More information about the Haskell-Cafe mailing list