Thanks Tim, Yes, profiling suggest that ffts are the main contributor. I remember the discussion (https://groups.google.com/d/msg/julia-users/kV-sKVFR2n0/X9F86aVKWDIJ), and I suppose we could come to the same conclusions, however I could be that I've overlooked something elementary. I was postponing the preplanning part but I guess it's inevitable.
Cheers, Oliver Den onsdag den 18. juni 2014 13.40.10 UTC+2 skrev Tim Holy: > > Have you profiled it? Is most of the time spent in the ffts? Assuming it > is the > ffts that dominate, try preplanning with FFTW.MEASURE or FFTW.PATIENT. > > I seem to recall that some months ago I posted some Matlab/Julia FFT > benchmarks to one of the mailing lists or the github repository. I suspect > that Matlab has some clever tricks up their sleeve for fft-planning---they > seem > to be able to settle on a good algorithm with much less time than I find I > need > with FFTW.MEASURE or FFTW.PATIENT. It would be lovely to figure out a > better > approach; with 3d FFTs I often find that to get good performance I need to > devote about 60s to planning for each different size I run, which is a bit > of a > pain. > > --Tim > > On Wednesday, June 18, 2014 03:35:06 AM Oliver Lylloff wrote: > > Hello all, > > > > I'm computing a 2D convolution with fft and seeing a timing difference > > between Matlab and Julia, with Matlab being about 2x faster than Julia. > > I've simplified my code down to an example (see gist here: > > https://gist.github.com/1oly/51f39a831cef3931e7b8). The bottleneck of > my > > code is evaluating the function > > > > function func(b,x,Fps) > > r = fftshift(ifft(fft(x).*Fps)) - b; > > return r > > end > > > > Timings are after one initial run to remove overhead and Matlab is > single > > thread. > > > > Matlab (-singleCompThread) = 0.0026s > > Julia = 0.005s > > > > Does other people see this difference as well? Any suggestions to > possible > > speed-ups? > > > > Best, > > Oliver > >
