[Python-ideas] Python 3000 TIOBE -3%

[Nick Coghlan]

On Sat, Feb 11, 2012 at 1:30 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Masklinn, 10.02.2012 16:12:
>> On 2012-02-10, at 15:59 , Stefan Behnel wrote:
>>>> GIL + Threads = Simplified, non parallel interpreter
>>>
>>> Note that this also applies to PyPy, so even "interpreter" isn't enough of
>>> a generalisation.
>>>
>>> I think it's best to speak of the GIL as what it is: a lock that protects
>>> internal state of the CPython runtime (and also some external code, when
>>> used that way). Rather convenient, if you ask me.
>>
>> It is very convenient from the viewpoint of implementing the interpreter,
>> but you must acknowledge that it comes with quite severe limitations on
>> the ability of user code to take advantage of computing resources.
>
> I don't think it does. See my other post just now in response to Massimo.

Armin Rigo's series on Software Transactional Memory on the PyPy blog
is also required reading for anyone seriously interested in practical
shared memory concurrency that doesn't impose a horrendous maintenance
burden on developers that try to use it:
http://morepypy.blogspot.com.au/2011/06/global-interpreter-lock-or-how-to-kill.html
http://morepypy.blogspot.com.au/2011/08/we-need-software-transactional-memory.html
http://morepypy.blogspot.com.au/2012/01/transactional-memory-ii.html

And for those that may be inclined to dismiss STM as pie-in-the-sky
stuff that is never going to be practical in the "real world", the
best I can offer is Intel's plans to bake an initial attempt at it
into a consumer grade chip within the next couple of years:
http://arstechnica.com/business/news/2012/02/transactional-memory-going-mainstream-with-intel-haswell.ars?

I do like Armin's analogy that free threading is to concurrency as
malloc() and free() are to memory management :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia