EMS-TU-Ilmenau / fastmat

A library to build up lazily evaluated expressions of linear transforms for efficient scientific computing.
https://fastmat.readthedocs.io
Apache License 2.0
24 stars 8 forks source link

Get rid of np.exp(...) to generate Bluestein Fourier Matrix #45

Closed MichaelDoebereiner closed 3 years ago

MichaelDoebereiner commented 5 years ago

I've determined that np.exp(...) might not have a good performance for large matrices. Maybe there's another way to create the Fourier Matrix in case of the Bluestein Fourier Transform.

SebastianSemper commented 5 years ago

Which part of the fastmat code are you referring to? Since the only time the np.exp(...) function is called in the Fourier class is during the initialization of the class instance. This is only done once during construction and as such not really a performance issue during the actual execution of the transforms.

If this is not what you meant, you should be a little bit more specific. ;-)

On Wed, 7 Nov 2018 at 12:40, MichaelDoebereiner notifications@github.com wrote:

I've determined that np.exp(...) might not have a good performance for large matrices. Maybe there's another way to create the Fourier Matrix in case of the Bluestein Fourier Transform.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EMS-TU-Ilmenau/fastmat/issues/45, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDZRn1_832L74Z0g04VOOFZtsxcTIeYks5ussaTgaJpZM4YSRWD .

MichaelDoebereiner commented 5 years ago

You're right, I'm referring to this part. Since this is called only once at this part of the code, you can take it as an annotation in general. ;-)

ChristophWWagner commented 5 years ago

I can confirm this is sort of performance-critical for larger orders. Assume you have an Fourier-based interpolator, this generation takes a couple of hundred ms for orders around ~1e6, which is not THAT large (but also not that small). I once observed bad performance when generating interpolator objects for varying data sizes but didn't attribute it to the exponential generation. If it is verified that that's the cause we should address it.

MichaelDoebereiner commented 5 years ago

I made a short example, where you can see that there are faster solutions than np.exp(). Allthough I don't know exactly what this numexpr module does. Even a straight forward solution with sine and cosine is faster than np.exp().

Example:

x = np.random.randn(1000000,1)1j %timeit np.exp(x) 70.4 ms ± 450 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) %timeit numexpr.evaluate('exp(x)') 16 ms ± 55 µs per loop (mean ± std. dev. of 7 runs, 100 loops each) x = np.random.randn(1000000,1) %timeit np.cos(x)+1jnp.sin(x) 46.6 ms ± 130 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

ChristophWWagner commented 3 years ago

Modifications were introduced in v0.2 by d22813f0452cd732976662987f2a2aae5c046019. Closing.