[Cython] Acquisition counted cdef classes

[Dag Sverre Seljebotn]

On 10/26/2011 11:45 AM, mark florisson wrote:
> On 26 October 2011 08:56, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> Greg Ewing, 26.10.2011 00:27:
>>>
>>> Dag Sverre Seljebotn wrote:
>>>
>>>> I'd gladly take a factor two (or even four) slowdown of CPython code any
>>>> day to get rid of the GIL :-). The thing is, sometimes one has 48 cores
>>>> and consider a 10x speedup better than nothing...
>>>
>>> Another thing to consider is that locking around refcount
>>> changes may not be as expensive in typical Cython code as
>>> it is in Python.
>>>
>>> The trouble with Python is that you can't so much as scratch
>>> your nose without touching a big pile of ref counts. But
>>> if the Cython code is only dealing with a few Python objects
>>> and doing most of its work at the C level, the relative
>>> overhead of locking around refcount changes may not be
>>> significant.
>>>
>>> So it may be worth trying the strategy of just acquiring
>>> the GIL whenever a refcount needs to be changed in a nogil
>>> section, and damn the consequences.
>>
>> Hmm, interesting. That would give new semantics to "nogil" sections,
>> basically:
>>
>> """
>> You can do Python interaction in nogil code, however, this will slow down
>> your code. Cython will generate C code to acquire and release the GIL around
>> any Python interaction that your code performs, thus serialising any calls
>> into the CPython runtime. If you want to avoid this serialisation, use
>> "cython -a" to find out where Python interaction happens and use static
>> typing to let Cython generate C code instead.
>> """
>>
>> In other words: "with gil" sections hold the GIL by default and give it away
>> on explicit request, whereas "nogil" sections have the GIL released by
>> default and acquire it on implicit need.
>>
>> The advantage over object level locking is that this does not increase the
>> in-memory size of the object structs, and that it works with *any* Python
>> object, not just extension types with a compile time known type.
>>
>> I kind of like that.
>
> My problem with that is that if there if any other python thread,
> you're likely just going to sleep for thousands of CPU cycles as that
> thread will keep the GIL. Doing this implicitly for operations with
> such overhead would be unacceptable. I think writing 'with gil:' is
> fine, it's the performance that's the problem in the first place which
> prevents you from doing that, not the 9 characters you need to type.

I'm with Stefan here. We have more or less the exact same problem if you 
inadvertendly do arithmetic with Python floats rather than C doubles. 
The workflow then is to check the HTML for yellow lines. Same with the 
GIL (we could even introduce a new color in the HTML report for where 
you hold the GIL and not).

The advice to get fast code is

But, we should also introduce directives that emit warnings in both of 
these situations, that you can use while developing to quickly pinpoint 
source code lines ("Type of variable not inferred", "GIL automatically 
acquired").

DS

>
> What I would like is having Cython infer whether the GIL is needed for
> a function, and mark it "implicitly nogil", so it can be called from
> nogil contexts without actually having to declare it nogil. This would
> only work for non-extern things, and you would still need to declare
> it nogil in your pxd if you want to export it. Apparently many users
> (even those that have used Cython quite a bit) are confused with what
> nogil on functions actually does (or they are not even aware it
> exists).
>
>> Stefan
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel