[Haskell-cafe] Re: Python's big challenges,
Haskell's big advantages?
wnoise at ofb.net
Wed Sep 17 16:29:30 EDT 2008
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;
> systems that don't use an existing user-space thread library (such as
> Concurrent Haskell or libthread ) emulate user-space threads by
> keeping a pool of processors and re-using them (e.g., IIUC Apache does
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.
More information about the Haskell-Cafe