From whitegoldrock at gmail.com  Sun Mar 21 14:23:23 2021
From: whitegoldrock at gmail.com (Golden Rockefeller)
Date: Sun, 21 Mar 2021 11:23:23 -0700
Subject: [Cython] Overhead in MemoryviewSlice Conversion?
Message-ID: <CAJeN5w+OZUUdHpLatzjLJyHqt7EtgxgxvmACNNHqe4vfCTUiGA@mail.gmail.com>

I know there has been some work last year at improving the overhead in
creating cython.view.arrays (cvarray). But I have noticed a large overhead
in converting that cvarray to a memoryview (e.g  double[:]). I would like
some advice in inspecting cython's source code.

For example, where can I find
"__Pyx_PyObject_to_MemoryviewSlice_ds_double"?




Through testing, my guess is that this function introduces most of the
overhead:
"""

@timefunc("cvarray_to_memoryview")

def _(Py_ssize_t L):

cdef Py_ssize_t i

cdef double* arrptr

cdef cvarray cvarr

cdef double[:] arr

for i in range(loops):

arrptr = <double*> malloc(sizeof(double) * L)

cvarr = cvarray((L,),sizeof(double),'d', mode="c", allocate_buffer=False)

cvarr.callback_free_data = free

cvarr.data = <char *> arrptr

arr = cvarr # Only difference is this conversion


# Prevents dead code elimination

str(arr[0])

@timefunc("cvarray")

def _(Py_ssize_t L):

cdef Py_ssize_t i

cdef cvarray cvarr = cvarray((L,),sizeof(double),'d')


for i in range(loops):

arrptr = <double*> malloc(sizeof(double) * L)

cvarr = cvarray((L,),sizeof(double),'d', mode="c", allocate_buffer=False)

cvarr.callback_free_data = free

cvarr.data = <char *> arrptr


# Prevents dead code elimination

str(cvarr[0])

"""
Timings (loops = 100000; L in [1, 10, 100, 1000, 10000])

Running cvarray_to_memoryview

1.555391 1.510217 1.518601 1.503522 1.733853 ?s

Running cvarray

0.342308 0.353832 0.335155 0.361952 0.518414 ?s

Golden Rockefeller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cython-devel/attachments/20210321/4c24819e/attachment.html>

From stefan_ml at behnel.de  Wed Mar 24 15:50:17 2021
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 24 Mar 2021 20:50:17 +0100
Subject: [Cython] Anything to include in the next 3.0 alpha release?
Message-ID: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>

Hi,

I'll prepare a new 3.0 alpha release during the next days. If you have or
know anything that is ready for inclusion that I should take a look at,
please send me a quick note.

Stefan

From dalcinl at gmail.com  Wed Mar 24 16:27:20 2021
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Wed, 24 Mar 2021 23:27:20 +0300
Subject: [Cython] Anything to include in the next 3.0 alpha release?
In-Reply-To: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
References: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
Message-ID: <CAEcYPwBM3WV4j4GvtkPZBvrWe9m_OKidSEfe4NsvGoXHUoVDxg@mail.gmail.com>

On Wed, 24 Mar 2021 at 23:08, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Hi,
>
>
Hi Stefan,


> I'll prepare a new 3.0 alpha release during the next days. If you have or
> know anything that is ready for inclusion that I should take a look at,
> please send me a quick note.
>
>
Years, ago, I contributed some bits of what today is the autodoc transform
(#cython: embedsignature=True).
I have a reimplementation of this transform for use within mpi4py
https://github.com/mpi4py/mpi4py/blob/master/conf/cyautodoc.py
The main feature of this reimplementation is to render types using
annotation typing.
The  purpose is twofold: the signatures in docstrings look much better, and
they are also good enough to generate typing stuff by simply copying over
the signature Cython generates.
So, I have this ad hoc script that extracts signatures from the first
docstring line and generates *.pyi stubs for mpi4py:
https://github.com/mpi4py/mpi4py/blob/master/conf/mpistubgen.py
The ah hoc stubgen script generates the following MPI.pyi stub file:
https://github.com/mpi4py/mpi4py/blob/master/src/mpi4py/MPI.pyi
I insist: all the signatures you see in that MPI.pyi stub file is a
verbatim copy of the first line of docstrigns Cython generates with the
reimplemented transform.

Do you think it would be worth pushing this reimplementation to Cython
to have it available in the upcoming 3.0?
The main and perhaps only drawback is that the output is not backward
compatible with the previous output.
But IMHO the new output looks way better and it is totally in line with the
new trend of using annotations and typing.

PS: I should have raised this proposal earlier, but I've been quite busy,
sorry about that.


-- 
Lisandro Dalcin
============
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cython-devel/attachments/20210324/328879c2/attachment.html>

From stefan_ml at behnel.de  Wed Mar 24 17:17:28 2021
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 24 Mar 2021 22:17:28 +0100
Subject: [Cython] Anything to include in the next 3.0 alpha release?
In-Reply-To: <CAEcYPwBM3WV4j4GvtkPZBvrWe9m_OKidSEfe4NsvGoXHUoVDxg@mail.gmail.com>
References: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
 <CAEcYPwBM3WV4j4GvtkPZBvrWe9m_OKidSEfe4NsvGoXHUoVDxg@mail.gmail.com>
Message-ID: <b7fb6d0a-cc13-54d4-4995-0ad9298001fd@behnel.de>

Hi Lisandro! :)

Lisandro Dalcin schrieb am 24.03.21 um 21:27:
> On Wed, 24 Mar 2021 at 23:08, Stefan Behnel wrote:
>> I'll prepare a new 3.0 alpha release during the next days. If you have or
>> know anything that is ready for inclusion that I should take a look at,
>> please send me a quick note.
>>
> 
> Years, ago, I contributed some bits of what today is the autodoc transform
> (#cython: embedsignature=True).
> I have a reimplementation of this transform for use within mpi4py
> https://github.com/mpi4py/mpi4py/blob/master/conf/cyautodoc.py
> The main feature of this reimplementation is to render types using
> annotation typing.
> The  purpose is twofold: the signatures in docstrings look much better, and
> they are also good enough to generate typing stuff by simply copying over
> the signature Cython generates.
> So, I have this ad hoc script that extracts signatures from the first
> docstring line and generates *.pyi stubs for mpi4py:
> https://github.com/mpi4py/mpi4py/blob/master/conf/mpistubgen.py
> The ah hoc stubgen script generates the following MPI.pyi stub file:
> https://github.com/mpi4py/mpi4py/blob/master/src/mpi4py/MPI.pyi
> I insist: all the signatures you see in that MPI.pyi stub file is a
> verbatim copy of the first line of docstrigns Cython generates with the
> reimplemented transform.
> 
> Do you think it would be worth pushing this reimplementation to Cython
> to have it available in the upcoming 3.0?
> The main and perhaps only drawback is that the output is not backward
> compatible with the previous output.
> But IMHO the new output looks way better and it is totally in line with the
> new trend of using annotations and typing.
> 
> PS: I should have raised this proposal earlier, but I've been quite busy,
> sorry about that.

Probably not something for the next alpha, but yes, that would be nice. And
3.0 is the right time to make this change.

Requires a proper PR, though, and a bunch of tests that make sure that what
we generate here is reasonable and correct, especially in the light of
Cython's pure Python type annotations. Also thinking of C++ types here?

Stefan

From dw-git at d-woods.co.uk  Wed Mar 24 17:50:36 2021
From: dw-git at d-woods.co.uk (da-woods)
Date: Wed, 24 Mar 2021 21:50:36 +0000
Subject: [Cython] Overhead in MemoryviewSlice Conversion?
In-Reply-To: <CAJeN5w+OZUUdHpLatzjLJyHqt7EtgxgxvmACNNHqe4vfCTUiGA@mail.gmail.com>
References: <CAJeN5w+OZUUdHpLatzjLJyHqt7EtgxgxvmACNNHqe4vfCTUiGA@mail.gmail.com>
Message-ID: <3b676e65-922a-7c40-7c57-066e3bf89c99@d-woods.co.uk>

They're generated using a string-substitution tool (and thus hard to 
search for). But the code is 
https://github.com/cython/cython/blob/8609e0fa7d361f1392823ff6e1a618720cd62df3/Cython/Utility/MemoryView_C.c#L130. 
I found it by searching for "ObjectToMemviewSlice ", which appears just 
above the prototype in the generated C code.

My impression is that creating memoryview slices isn't always hugely 
quick - I think the old np.ndarray syntax can be a little quicker to 
create (although it's worse in other ways)



On 21/03/2021 18:23, Golden Rockefeller wrote:
> I know there has been some work last year at improving the overhead in 
> creating cython.view.arrays (cvarray). But I have noticed a large 
> overhead in converting that cvarray to a memoryview (e.g? double[:]). 
> I would like some advice in inspecting cython's source code.
>
> For example, where can I find 
> "__Pyx_PyObject_to_MemoryviewSlice_ds_double"?
>
>
>
>
> Through testing, my guess is that this function introduces most of the 
> overhead:
> """
>
> @timefunc("cvarray_to_memoryview")
>
> def _(Py_ssize_t L):
>
> cdef Py_ssize_t i
>
> cdef double* arrptr
>
> cdef cvarray cvarr
>
> cdef double[:] arr
>
> for i in range(loops):
>
> arrptr = <double*> malloc(sizeof(double) * L)
>
> cvarr = cvarray((L,),sizeof(double),'d', mode="c", allocate_buffer=False)
>
> cvarr.callback_free_data = free
>
> cvarr.data = <char *> arrptr
>
> arr = cvarr # Only difference is this conversion
>
> # Prevents dead code elimination
>
> str(arr[0])
>
> @timefunc("cvarray")
>
> def _(Py_ssize_t L):
>
> cdef Py_ssize_t i
>
> cdef cvarray cvarr = cvarray((L,),sizeof(double),'d')
>
> for i in range(loops):
>
> arrptr = <double*> malloc(sizeof(double) * L)
>
> cvarr = cvarray((L,),sizeof(double),'d', mode="c", allocate_buffer=False)
>
> cvarr.callback_free_data = free
>
> cvarr.data = <char *> arrptr
>
> # Prevents dead code elimination
>
> str(cvarr[0])
>
> """
>
> Timings (loops = 100000; L in [1, 10, 100, 1000, 10000])
>
> Running cvarray_to_memoryview
>
> 1.555391 1.510217 1.518601 1.503522 1.733853 ?s
>
> Running cvarray
>
> 0.342308 0.353832 0.335155 0.361952 0.518414 ?s
>
>
> Golden Rockefeller
>
>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cython-devel/attachments/20210324/cda49ab5/attachment-0001.html>

From dw-git at d-woods.co.uk  Wed Mar 24 17:18:36 2021
From: dw-git at d-woods.co.uk (da-woods)
Date: Wed, 24 Mar 2021 21:18:36 +0000
Subject: [Cython] Anything to include in the next 3.0 alpha release?
In-Reply-To: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
References: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
Message-ID: <11ef0588-f6e3-f871-30f3-c06de0adc13c@d-woods.co.uk>

https://github.com/cython/cython/pull/3804 (__del__ in cdef classes) 
looks pretty complete to me.

https://github.com/cython/cython/pull/3743 (duplicate utility code) is 
hopefully also pretty complete and does fix some bugs that have been 
recurred a few times.

David



On 24/03/2021 19:50, Stefan Behnel wrote:
> Hi,
>
> I'll prepare a new 3.0 alpha release during the next days. If you have or
> know anything that is ready for inclusion that I should take a look at,
> please send me a quick note.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel



From dalcinl at gmail.com  Thu Mar 25 03:10:16 2021
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Thu, 25 Mar 2021 10:10:16 +0300
Subject: [Cython] Anything to include in the next 3.0 alpha release?
In-Reply-To: <b7fb6d0a-cc13-54d4-4995-0ad9298001fd@behnel.de>
References: <259c41ac-7cca-5ee8-6aed-a940e9e716f2@behnel.de>
 <CAEcYPwBM3WV4j4GvtkPZBvrWe9m_OKidSEfe4NsvGoXHUoVDxg@mail.gmail.com>
 <b7fb6d0a-cc13-54d4-4995-0ad9298001fd@behnel.de>
Message-ID: <CAEcYPwAV6r_pKsXbJMZsUfMqERMH_foFgzDuY6DpgT51b+ON7A@mail.gmail.com>

On Thu, 25 Mar 2021 at 00:17, Stefan Behnel <stefan_ml at behnel.de> wrote:

>
> Probably not something for the next alpha, but yes, that would be nice.


This actually removes some pressure for me :-), I don't have to work on it
right now.


> And 3.0 is the right time to make this change.
>
>
OK, great.


> Requires a proper PR, though, and a bunch of tests


Yes, of course.


> that make sure that what
> we generate here is reasonable and correct, especially in the light of
> Cython's pure Python type annotations.


I think pure Python is not going to be the problem, but what to do with
C/C++ types, and the interaction with the annotation typing directive.


> Also thinking of C++ types here?
>
>
OK. Material for further discussion.

Regards,

-- 
Lisandro Dalcin
============
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cython-devel/attachments/20210325/f2eee659/attachment.html>