[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D.
These are binary wheel installs though, no? Which means 3.8 version and 3.10 version were compiled at different times, even for the same NumPy version. Also for different platforms, I don't know which you are on. I haven't checked what's on PyPI for each version. I think PyFFT is largely using Num

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Christopher Barker
On Sun, Dec 19, 2021 at 1:46 PM MRAB wrote: > On 2021-12-19 20:06, Tigran Aivazian wrote: > > So far I have narrowed it down to a block of code in solve.py doing a > lot of multi-threaded FFT (i.e. with fft(..., threads=6) of pyFFTW), as > well as numpy exp() and other functions and pure Python h

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread MRAB
On 2021-12-19 20:06, Tigran Aivazian wrote: So far I have narrowed it down to a block of code in solve.py doing a lot of multi-threaded FFT (i.e. with fft(..., threads=6) of pyFFTW), as well as numpy exp() and other functions and pure Python heavy list manipulation (yes, lists, not numpy arrays

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
I have got it narrowed down to the "threads=6" argument of fft() and ifft() functions of pyFFTW! Namely, if I do NOT pass "threads=6" to fft()/iff(), then the parallel execution of multiple instances of the scripts is the same in Python 3.8 and 3.10. But it is a bit slower than with "threads=6",

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
So far I have narrowed it down to a block of code in solve.py doing a lot of multi-threaded FFT (i.e. with fft(..., threads=6) of pyFFTW), as well as numpy exp() and other functions and pure Python heavy list manipulation (yes, lists, not numpy arrays). All of this together (or some one part of

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Mats Wichmann
On 12/19/21 06:46, aivazian.tig...@gmail.com wrote: > Hello, > > Being a programmer myself I realise that a report on performance degradation > should ideally contain a small test program that clearly reproduces the > problem. However, unfortunately, I do not have the time at present to isolate

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
I have created four different sets of initial data, one for each thread of execution and no, unfortunately, that does NOT solve the problem. Still, when four threads are executed in parallel, 3.8 outperforms 3.10 by a factor of 2.4. So, there is some other point of contention between the threads

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
I think I have found something very interesting. Namely, I removed all multiprocessing (which is done in the shell script, not in Python) and so reduced the program to just a single thread of execution. And lo and behold, Python 3.10 now consistently beats 3.8 by about 5%. However, this is not t

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Sebastian Berg
On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote: > To eliminate the possibility of being affected by the different > versions of numpy I have just now upgraded numpy in Python 3.8 > environment to the latest version, so both 3.8 and 3.10 and using > numpy 1.21.4 and still the timing is exa

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D.
Not the version, but the build. Did you compile NumPy from source using the same compiler with both Python versions? If not, that remains my strong hunch about performance difference. Given what your programs do, it sure seems like the large majority of runtime is spent in supporting numeric libra

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
In both cases I installed numpy using "sudo -H pip install numpy". And just now I upgraded numpy in 3.8 using "sudo -H pip3.8 install --upgrade numpy". I will try to simplify the program by removing all the higher level complexity and see what I find.

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
Alas, it is exactly the same as previously reported, so the problem persists. If it was exactly the same between Python versions I would celebrate and shout for joy, seeing that the problem is narrowed down to numpy. I can carefully upgrade all the other packages in 3.8 to match those in 3.10.

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Paul Bryan
"Exactly the same" between Python versions, or exactly the same as previously reported? On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote: > To eliminate the possibility of being affected by the different > versions of numpy I have just now upgraded numpy in Python 3.8 > environment to the

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread Tigran Aivazian
To eliminate the possibility of being affected by the different versions of numpy I have just now upgraded numpy in Python 3.8 environment to the latest version, so both 3.8 and 3.10 and using numpy 1.21.4 and still the timing is exactly the same. ___

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

2021-12-19 Thread David Mertz, Ph.D.
My guess is that this difference is predominantly different builds of NumPy. For example, the Intel optimized builds are very good, and a speed difference of the magnitude shown in this note are typical. E.g. https://www.intel.com/content/www/us/en/developer/articles/technical/numpyscipy-with-int