[Python-Dev] Exploration PEP : Concurrency for moderately massive (4 to 32 cores) multi-core architectures (original) (raw)

Guido van Rossum guido at python.org
Wed Sep 19 05:24:28 CEST 2007

On 9/18/07, Krishna Sankar <ksankar at doubleclix.net> wrote:

The vagueness is deliberate, to keep the options open until we have some form o convergence. Parallelism/concurrency is a vast and important domain that I do not want to develop a hasty proposal. But I did want to start thinking in terms of concrete proposals, not pontifying, hence the "pragmatic" section.

As long as it's this vague it doesn't deserve to be called a PEP though. PEPs can't be vague, they must make specific proposals. As long as this is intentionally half-baked it belongs back in python-ideas and there's no point in pretending to be writing a "PEP".

Happy to hear that you are open to PVM changes. It will not be asked unless and until we all are crisp about it. Cheers

Guido van Rossum wrote: > On 9/18/07, Krishna Sankar <ksankar at doubleclix.net> wrote: > >> Folks, >> As a follow-up to the py3k discussions started by Bruce and Guido, I >> pinged Brett and he suggested I submit an exploratory proposal. Would >> appreciate insights, wisdom, the good, the bad and the ugly. >> >> A) Does it make sense ? >> B) Which application sets should we consider in designing the >> interfaces and implementations >> C) In this proposal, parallelism and concurrency are used in an >> interchangeable fashion. Thoughts ? >> D) Please suggest pertinent links, discussions and insights. >> E) I have kept the proposal to a minimum to start the discussions and >> to explore if this is the right thing to do. Collaboratively, as we >> zero-in on one or two approaches, the idea is to expand it to a crisp >> and clear PEP. Need to do some more formatting as well. >> > > I'd say it is a little light on specific proposals. The only section > that actually proposes anything is this: > > >> Pragmatic proposal >> ------------------ >> May I suggest we embed two primitives in Python 3K: >> A) A functional style share-nothing set of interfaces (and >> implementations thereof) - provides the task parallelism/concurrency >> capability, "small messages, big computations" as Joe Armstrong calls it[3] >> B) A limited shared memory based model for data intensive parallelism >> >> Most probably this would be part of stdlib. While Guido is almost right >> in saying that this is a (std)library problem, it is not fully so. We >> would need a few primitives from the underlying PVM substrate. Possibly >> one reason for Guido's position is the lack of clarity as to what needs >> to be changed and why. IMHO, just saying take GIL off does not solve the >> problem either. >> > > Before I can meaningfully comment I think I'd like to hear more about > what specifically you are thinking of. > > I don't mind the necessary changes to the PVM. I do like to see how > this affects existing C extensions though. > >

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list