Re: [Cython] Bindings performance issue
On 31 May 2011 20:25, Vitja Makarov wrote:
> Hi!
>
> Is bindings performance issue valuable?
>
> $ cat bindbench.pyx
> def wo_bindings():
> pass
>
> def outer():
> def inner():
> pass
> return inner
> with_bindings = outer()
>
> $ python
import timeit
timeit.repeat('with_bindings()', setup='from bindbench import wo_bindings,
with_bindings', repeat=1, number=1)
> [6.169871807098389]
timeit.repeat('wo_bindings()', setup='from bindbench import wo_bindings,
with_bindings', repeat=1, number=1)
> [4.609416961669922]
>
> PyCBindings makes it 1.3 (difference is about 15ns on my laptop) times
> slower for CPython interpreter execution.
> As CPython has some optimizations for CFunctions and PyCFunctions.
>
> Does it make sense for us? Or we can easily switch to bindings?
>
> --
> vitja.
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
I think switching should be fine, if you'd desperately need the speed
you'd be calling c(p)def functions from Cython. In fact, when the
fused cfunction will be ready it will be even slightly slower, as it
overrides the tp_call. But perhaps that should really be made into a
subclass...
Anyway, would you use these for Python classes and module-level def
functions (and closures) only, or would you also use them in extension
classes? Because I found at least a bit of problem there, as extension
class methods get 'self' passed as the first argument to the C
function (as PyCFunctionObject.m_self), whereas methods in Python
classes get 'self' passed in the args tuple (and the m_self is
unused).
Mark
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bindings performance issue
2011/6/1 mark florisson :
> On 31 May 2011 20:25, Vitja Makarov wrote:
>> Hi!
>>
>> Is bindings performance issue valuable?
>>
>> $ cat bindbench.pyx
>> def wo_bindings():
>> pass
>>
>> def outer():
>> def inner():
>> pass
>> return inner
>> with_bindings = outer()
>>
>> $ python
> import timeit
> timeit.repeat('with_bindings()', setup='from bindbench import
> wo_bindings, with_bindings', repeat=1, number=1)
>> [6.169871807098389]
> timeit.repeat('wo_bindings()', setup='from bindbench import wo_bindings,
> with_bindings', repeat=1, number=1)
>> [4.609416961669922]
>>
>> PyCBindings makes it 1.3 (difference is about 15ns on my laptop) times
>> slower for CPython interpreter execution.
>> As CPython has some optimizations for CFunctions and PyCFunctions.
>>
>> Does it make sense for us? Or we can easily switch to bindings?
>>
>> --
>> vitja.
>> ___
>> cython-devel mailing list
>> cython-devel@python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>
> I think switching should be fine, if you'd desperately need the speed
> you'd be calling c(p)def functions from Cython. In fact, when the
> fused cfunction will be ready it will be even slightly slower, as it
> overrides the tp_call. But perhaps that should really be made into a
> subclass...
>
> Anyway, would you use these for Python classes and module-level def
> functions (and closures) only, or would you also use them in extension
> classes? Because I found at least a bit of problem there, as extension
> class methods get 'self' passed as the first argument to the C
> function (as PyCFunctionObject.m_self), whereas methods in Python
> classes get 'self' passed in the args tuple (and the m_self is
> unused).
>
Recently I've found a problem with static methods (__new__ for
example) of inner classes (classes created inside a function, for
instance)
I think binding version should be used for all regular def functions
(defs, staticmethods, classmethods and so on).
I also think that it's better to rename binding_PyCFunction_Type to
something like CyFunctionType and make it more like PyFunction.
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bindings performance issue
On Wed, Jun 1, 2011 at 7:26 AM, Vitja Makarov wrote:
> 2011/6/1 mark florisson :
>> On 31 May 2011 20:25, Vitja Makarov wrote:
>>> Hi!
>>>
>>> Is bindings performance issue valuable?
>>>
>>> $ cat bindbench.pyx
>>> def wo_bindings():
>>> pass
>>>
>>> def outer():
>>> def inner():
>>> pass
>>> return inner
>>> with_bindings = outer()
>>>
>>> $ python
>> import timeit
>> timeit.repeat('with_bindings()', setup='from bindbench import
>> wo_bindings, with_bindings', repeat=1, number=1)
>>> [6.169871807098389]
>> timeit.repeat('wo_bindings()', setup='from bindbench import wo_bindings,
>> with_bindings', repeat=1, number=1)
>>> [4.609416961669922]
>>>
>>> PyCBindings makes it 1.3 (difference is about 15ns on my laptop) times
>>> slower for CPython interpreter execution.
>>> As CPython has some optimizations for CFunctions and PyCFunctions.
>>>
>>> Does it make sense for us? Or we can easily switch to bindings?
>>>
>>> --
>>> vitja.
>>> ___
>>> cython-devel mailing list
>>> cython-devel@python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>
>>
>> I think switching should be fine, if you'd desperately need the speed
>> you'd be calling c(p)def functions from Cython. In fact, when the
>> fused cfunction will be ready it will be even slightly slower, as it
>> overrides the tp_call. But perhaps that should really be made into a
>> subclass...
Yes, this should be a subclass, slowing all calls down is a bad idea.
>> Anyway, would you use these for Python classes and module-level def
>> functions (and closures) only, or would you also use them in extension
>> classes? Because I found at least a bit of problem there, as extension
>> class methods get 'self' passed as the first argument to the C
>> function (as PyCFunctionObject.m_self), whereas methods in Python
>> classes get 'self' passed in the args tuple (and the m_self is
>> unused).
>>
>
> Recently I've found a problem with static methods (__new__ for
> example) of inner classes (classes created inside a function, for
> instance)
> I think binding version should be used for all regular def functions
> (defs, staticmethods, classmethods and so on).
+1 to moving that way. (Well, static and class methods bind
differently, right?)
> I also think that it's better to rename binding_PyCFunction_Type to
> something like CyFunctionType and make it more like PyFunction.
+1
Is there any advantage to the method descriptors (other than that
they're easier for a human to write?)
I think that small speed regression for better compatibility is OK if
we add a directive to not create binding functions. (It'd be nice if
we could work around it, but that's hard as CPython has special
hooks...) The bigger issue is that the binding behavior is backwards
incompatible, and perhaps in a subtle way. Perhaps we need to have a
phase where all currently non-binding functions that will become
binding functions will raise an error (or at least a warning) to wean
people off of the old behavior before making a switch.
- Robert
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
