Mailman 3 July 2018 - cython-devel

Re: [Cython] [cython-users] [Scipy-Dev] FFT from Cython
by Ian Henriksen July 30, 2018

July 30, 2018

Actually, this seems like a pretty reasonable SciPy feature request. Feel free to open an issue there. Thanks, Ian Henriksen On Mon, Jul 30, 2018 at 3:18 PM 'Chris Barker' via cython-users < cython-users(a)googlegroups.com> wrote: > BTW, > > Please don't spam so many lists with the same question. cython-users is > the right one for this. > > -CHB > > > > On Mon, Jul 30, 2018 at 10:50 AM, Chris Barker <chris.barker(a)noaa.gov> > wrote: > >> On Sun, Jul 29, 2018 at 6:17 PM, Eleftherios Garyfallidis < >> garyfallidis(a)gmail.com> wrote: >> >>> For a project in DIPY (http://dipy.org) we need to be calling 1D and 2D >>> FFTs and iFFTs very often. For this reason the most efficient way seems to >>> be through Cython. >>> >>> It would be great if we could call scipy's fft or numpy's fft without >>> the overhead. >>> >> >> have you profiled the overhead? Is it really significant? I"d expect the >> answer would only be yes if you were doing a lot of really small arrays -- >> is that the case? >> >> -CHB >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE >> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g> >> (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> Chris.Barker(a)noaa.gov >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE > <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g> > (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker(a)noaa.gov > > -- > > --- > You received this message because you are subscribed to the Google Groups > "cython-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cython-users+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

1 0

[Scipy-Dev] FFT from Cython
by Eleftherios Garyfallidis July 30, 2018

July 30, 2018

Hello all, For a project in DIPY (http://dipy.org) we need to be calling 1D and 2D FFTs and iFFTs very often. For this reason the most efficient way seems to be through Cython. It would be great if we could call scipy's fft or numpy's fft without the overhead. I would like to ask if someone has worked on this and can share some of hers/his experience or code. What we are trying to do is avoid increasing our dependencies. For example we prefer not using FFTW if this is not available in scipy/numpy. Finally, many thanks to scipy devs and cython devs for making available BLAS and LAPACK functions from Cython. This has been super useful for our project. I hope we can do something similar for FFT. Let me know if you have any ideas. Can we for example access the FFT functions of scipy directly from Cython. Has someone done this? Best regards, Eleftherios

1 0

Cython compilation speed vs. installed binary module sizes
by Stefan Behnel July 4, 2018

July 4, 2018

Hi all, when building Cython, it compiles a couple of its own modules. I was interested in what this brings for the separate parts of the compiler, so I used the compilation of Cython's compiled modules as benchmark and compiled the separate parts incrementally, using the latest CPython 3.7.0. Baseline, uncompiled Python run: real 0m14.972s user 0m14.565s sys 0m0.165s Compiling the parser: Cython/Compiler/Scanning.py Cython/Plex/Scanners.py Cython/Plex/Actions.py Cython/Compiler/Parsing.py real 0m13.614s user 0m13.320s sys 0m0.136s Additionally: Cython/Compiler/Visitor.py Cython/Compiler/FlowControl.py real 0m7.857s user 0m7.778s sys 0m0.074s Additionally: Cython/Compiler/Code.py Cython/StringIOTree.py real 0m7.356s user 0m7.068s sys 0m0.102s Only compiling the tree visitor and the control flow analysis: Cython/Compiler/Visitor.py Cython/Compiler/FlowControl.py real 0m9.029s user 0m8.899s sys 0m0.082s These are the current shared library sizes on my machine: 57040 Cython/Plex/Actions.cpython-37m-x86_64-linux-gnu.so 72592 Cython/StringIOTree.cpython-37m-x86_64-linux-gnu.so 78880 Cython/Runtime/refnanny.cpython-37m-x86_64-linux-gnu.so 86384 Cython/Plex/Scanners.cpython-37m-x86_64-linux-gnu.so 127952 Cython/Compiler/Pythran.cpython-37m-x86_64-linux-gnu.so 227480 Cython/Compiler/Scanning.cpython-37m-x86_64-linux-gnu.so 322136 Cython/Compiler/Visitor.cpython-37m-x86_64-linux-gnu.so 559864 Cython/Tempita/_tempita.cpython-37m-x86_64-linux-gnu.so 598712 Cython/Compiler/FlowControl.cpython-37m-x86_64-linux-gnu.so 902904 Cython/Compiler/Parsing.cpython-37m-x86_64-linux-gnu.so 1133176 Cython/Compiler/Code.cpython-37m-x86_64-linux-gnu.so 4167120 insgesamt This suggests that by only compiling the 6 modules of the scanner, parser, tree visitor and CFA, we get about half the binary sizes, but almost the same speed. One caveat: Being pure Python, Cython does not use all that many of its own language features, so other code might suffer more or less. I also tried lxml's main module, and it compiles about 7% slower when removing Code.so. Given that it's the biggest of the modules, that feels acceptable for me, so I removed Code, Pythran, Lexicon and StringIOTree from the list of compiled modules for now. Stefan

1 0