Adding multithreading to scipy.fft

peterbell10
Published: 08/12/2019

What did you do this week?

  • Fixed a small inconsistency with the numpy.fft API when the transform shape is given but not the axes (scipy#10594)
  • Gotten my CuPy PR into a review ready state. Fixing uarray backend support (scipy#2355)
  • Migrated pypocketfft from OpenMP to a custom thread-pool that I wrote to handle fork on POSIX systems. This addresses all the main concerns with adding OpenMP into SciPy (pypocketfft!23, pypocketfft!24)
  • Using the updated pypocketfft, I was then able to open a PR adding multithreading support to the scipy.fft API (scipy#10614)

What is coming up next?

- Create, or at least open issue for, a mkl-fft backend
- Expand the scipy.fft tutorial to include installing and using new FFT backends

There are also a number of minor features that could be added to pypocketfft such as shape changing transforms or pre-planned transforms. Though at this late stage in the project, my focus is on polishing the current feature set.

Did you get stuck anywhere?

No significant blockers this week.

 

View Blog Post

CuPy backend and pypocketfft cleanup

peterbell10
Published: 08/06/2019

What did you do this week?

  • I have opened a PR on cupy adding a scipy.fft backend
  • Fixed a few small incompatibilities with the numpy.fft interface
  • Updated next_fast_len, a utility function to find the fastest lengths for computing the FFT (pypocketfft!17, scipy#10570)
  • Various clean-ups and refactoring of pypocketfft's multi-dimensional transform functions (pypocketfft!16, pypocketfft!20)
  • Restarted a discussions about use of OpenMP in SciPy. pypocketfft already supports OpenMP for parallelising transforms over multidimensional arrays, however there are a number of issues preventing SciPy from building with this feature enabled.

What is coming up next?

  • Replace OpenMP in pypocketfft with a custom thread-pool. The discussions on SciPy-dev have suggested that OpenMP isn't going to be a suitable solution so I will attempt to replace it.
  • Finishing up my CuPy backend PR. It is mostly completed but needs a few more tests.
  • Implement shape-changing transforms in pypocketfft.

Did you get stuck anywhere?

I found it quite difficult to get cuda and CuPy working properly on my computer and still occasionally have problems with it stopping recognising my cuda device. However, it's at least functional now if not quite perfect.

 

View Blog Post

So long, FFTPACK

peterbell10
Published: 07/29/2019

What did you do this week?


Perhaps the most significant task this week was completely removing the fortran FFTPACK code from SciPy and rewriting scipy.fftpack using scipy.fft's pocketfft backend. This drastically simplifies the code with a diff of -8,856 lines of code.

I've also made a number of smaller improvements to scipy.fft as well as a significant performance improvement to scipy.signal.fftconvolve.

The first scipy.fft backend has also been created after my pyFFTW PR was merged this week. This means that SciPy users can accelerate their FFT transforms with all of pyFFTW's features using nothing more than a few function calls.

What is coming up next?

  • Adding a CuPy backend for scipy.fft
  • Implementing efficient shape-changing transforms in pypocketfft
  • Writing tests for the pyFFTW real-to-real transforms PR
  • Adding the ability to query active backends for uarray


Did you get stuck anywhere?

No blockers this week.

 

View Blog Post

Backend support merged

peterbell10
Published: 07/22/2019

What did you do this week?

This has been a very exciting week for me, with lots of progress made on my GSoC project. For the past couple of months I've been working on adding the new scipy.fft module which supercedes the existing scipy.fftpack submodule and adds a range of new features and interface improvements. Chief among these planned features was a backend system, allowing users to install their own fft libraries as implementations for the scipy.fft interface.

I'm pleased to say that this week, my backend PR was merged into master. scipy.fft can now be implemented by any backend supporting the uarray protocol and provides a range of ways for the user to control their installed backends [1]. Around the same time, it was also announced that I've officially been accepted into the scipy core developers along with one of my mentors - Greg.

But even with my projects main goals out of the way, there are still a number of improvements and stretch goals that I've been working on:

  • continued work on a pyFFTW backend which should be merged soon (pyFFTW#269)
  • improved normalization of idct/idst which is inconsistent in scipy.fftpack (scipy#10470)
  • improved the performance of the n-dimensional FFT interface (scipy#10490)
  • a new PR wrapping pypocketfft new sine and cosine transforms (DCT & DST) (scipy#10493)

What is coming up next?

With the DCT and DST transforms now in pypocketfft, the scipy.fft submodule will no longer depend on scipy.fftpack for any of it's transforms. So, it should be time to flip the dependecy on its head and remove all of the old fortran fftpack code, replacing it with a very thin wrapper around scipy.fft.

I can also work on one of the main stretch goals for this project which was finializing the addition of DCT and DST wrappers to pyFFTW. There has been a PR for this on pyFFTW for many years (pyFFTW#95) but they have lacked the man-power to finally finish it off and merge. Similar to pypocketfft, these real transforms were the
main feature missing from pyFFTW's interfaces.

Did you get stuck anywhere?

No blockers this week.

 

View Blog Post

For fork's sake - Fixing multiprocessing issues

peterbell10
Published: 07/15/2019

What did you do this week?

It was also reported that scipy.fft does not interact well with python's multiprocessing library. I was able to track down the issue and resolve it within a few hours, adding a unit test to ensure this wouldn't be broken again. However, when I went to update my uarray PR to use the new fast C++ version, the test started to fail. It turns out, the uarray multimethod objects needed to be pickleable in a very specific way that mimicks the behaviour of python Function types. Thankfully, after applying this fix the issue was resolved.

I've also this week:

  • added Hermitian symmetric transforms to scipy.fft (merged in scipy#10425)
  • added scipy.fft to the 1.4.0 release notes
  • updated my PR adding uarray support to scipy.fft
  • started work on adding a `scipy.fft` compatible interface to pyfftw in pyFFTW#269. This will be one of the first useful backend implementations for the new backend system.

What is coming up next?

The backend system PR is set to be merged very soon so I should be able to focus on adding the uarray protocol to pyfftw and possibly contributing compatible backends to other FFT libraries.

I can also work on pre-planned transforms.

Did you get stuck anywhere?

The multiprocessing incompatibilities posed an unexpected challange but I was able to work though the problems alright.

 

View Blog Post