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
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
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
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",
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
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
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
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
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
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
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.
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.
"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
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.
___
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
15 matches
Mail list logo