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

Krishna Sankar ksankar at doubleclix.net
Wed Sep 19 05:43:20 CEST 2007


Agreed it is not a PEP yet. Hence the word "Exploration" in front of it. 
This ia domain which needs some discussions before developing a good 
PEP. May be I should call it a PEPlet ;o)
Cheers
<k/>
Guido van Rossum wrote:
> 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
>> <k/>
>>
>> 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.
>>>
>>>
>>>       
>>     
>
>
>   



More information about the Python-Dev mailing list