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

[Aaron Denney]

On 2008-09-17, Jonathan Cast <jonathanccast at fastmail.fm> wrote:
> On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote:
>> On 2008-09-17, Arnar Birgisson <arnarbi at gmail.com> wrote:
>> > Hi Manlio and others,
>> >
>> > On Wed, Sep 17, 2008 at 14:58, Manlio Perillo <manlio_perillo at libero.it> wrote:
>> >>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534
>> >>>
>> >>> "cloud computing, transactional memory and future multicore processors"
>> >>>
>> >>
>> >> Multicore support is already "supported" in Python, if you use
>> >> multiprocessing, instead of multithreading.
>> >
>> > Well, I'm a huge Python fan myself, but multiprocessing is not really
>> > a solution as much as it is a workaround. Python as a language has no
>> > problem with multithreading and multicore support and has all
>> > primitives to do conventional shared-state parallelism. However, the
>> > most popular /implementation/ of Python sacrifies this for
>> > performance, it has nothing to do with the language itself.
>> 
>> Huh.  I see multi-threading as a workaround for expensive processes,
>> which can explicitly use shared memory when that makes sense.
>
> That breaks down when you want 1000s of threads.

This really misses the point I was going for.  I don't want 1000s of
threads.  I don't want *any* threads.  Processes are nice because you
don't have other threads of execution stomping on your memory-space
(except when explicitly invited to by arranged shared-memory areas).
It's an easier model to control side-effects in.  If this is too
expensive, and threads in the same situation will work faster, than I
might reluctantly use them instead.

> I'm not aware of any program, on any system, that spawns a new process
> on each event it wants to handle concurrently;

inetd

> systems that don't use an existing user-space thread library (such as
> Concurrent Haskell or libthread [1]) emulate user-space threads by
> keeping a pool of processors and re-using them (e.g., IIUC Apache does
> this).

Your response seems to be yet another argument that processes are too
expensive to be used the same way as threads.  In my mind pooling vs
new-creation is only relevant to process vs thread in the performance
aspects.  The fact that people use thread-pools means that they think
that even thread-creation is too expensive.  The central aspect in my
mind is a default share-everything, or default share-nothing.  One is
much easier to reason about and encourages writing systems that have
less shared-memory contention.

-- 
Aaron Denney
-><-