Strange computational time with fftn

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange computational time with fftn

Marco Caliari-4
Hi all,

anybody can explain me the strange peak in elapsed time I see in
computing fftn for dimension 100^3 with the default planner "estimate"?
Moreover, ml is twice as fast.
I attach the script and the result of the plot.
I'm on Linux Mint 19.3, octave 5.1.1 or 7.0.0, libfftw3 3.3.7

Thank you very much,

Marco



test_fftn.m (617 bytes) Download Attachment
fftn.png (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Strange computational time with fftn

Andreas Weber-6
Am 17.04.20 um 21:33 schrieb Marco Caliari:
> anybody can explain me the strange peak in elapsed time I see in
> computing fftn for dimension 100^3 with the default planner "estimate"?

I can see the same on my AMD Ryzen 5 2600 Six-Core Processor.
When reduzing the number of threads:

fftw ("threads", 4)

the peak is gone.

-- Andy


Reply | Threaded
Open this post in threaded view
|

Re: Strange computational time with fftn

Octave - General mailing list
In reply to this post by Marco Caliari-4


On 17/04/2020 22:33, Marco Caliari wrote:
Hi all,

anybody can explain me the strange peak in elapsed time I see in
computing fftn for dimension 100^3 with the default planner "estimate"?
Moreover, ml is twice as fast.
I attach the script and the result of the plot.
I'm on Linux Mint 19.3, octave 5.1.1 or 7.0.0, libfftw3 3.3.7

Thank you very much,

Marco


    

The problem is "estimate". I.e. FFTW does a really good job choosing codelets performing FFT of actual size on actual machine when it uses "measure". Because measure is brute force choosing of proper codelets.


"estimate" just guesses.


I suggest to spend time once using "measure" for your expected sizes on the actual machine - FFTW wisdom is preserved, so next times you won't spend time to create FFTW plans using "measure".


--Sergei.



Reply | Threaded
Open this post in threaded view
|

Re: Strange computational time with fftn

Marco Caliari-4
In reply to this post by Andreas Weber-6
On Fri, 17 Apr 2020 21:45:56 +0200
Andreas Weber <[hidden email]> wrote:

> Am 17.04.20 um 21:33 schrieb Marco Caliari:
> > anybody can explain me the strange peak in elapsed time I see in
> > computing fftn for dimension 100^3 with the default planner
> > "estimate"?  
>
> I can see the same on my AMD Ryzen 5 2600 Six-Core Processor.
> When reduzing the number of threads:
>
> fftw ("threads", 4)
>
> the peak is gone.
>
> -- Andy

With fftw ("threads", 4) or fftw ("threads", 8) I see a smaller peak
at n = 170.

Marco

--
Dr. Marco Caliari
Dipartimento di Informatica
Universita` degli Studi di Verona
Secondo piano, 2.03
Ca' Vignal 2
Strada le Grazie 15
37134 VERONA

tel: +39 045 802 7904
fax: +39 045 802 7068

Le informazioni trasmesse sono intese soltanto per la persona o l'ente
cui sono indirizzate e possono avere contenuto confidenziale e/o
riservato. La visione, la trasmissione, la diffusione o altro uso delle
informazioni di cui sopra e` proibita a chiunque ad esclusione del
legittimo destinatario. Se avete ricevuto queste informazioni per
errore, siete pregati di contattare il mittente e cancellare il
materiale ricevuto.

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.