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

On 2008-09-17, Jonathan Cast wrote:

On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote:

...

On 2008-09-17, Arnar Birgisson wrote:

...

Hi Manlio and others,

On Wed, Sep 17, 2008 at 14:58, Manlio Perillo wrote:

...

...

http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-fut...

"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 -><-