# Parallel computing NInverseFourierTransForm

I am running the code below, and it works perfectly. I have some function in Fourier space, and I take the numerical InverseFourierTransform. However, I will have to repeat this calculation often, and therefore I want to use ParallelTable. I've tried this, by replacing Table in the code below by ParallelTable. I am running the code on a computer with 8 kernels. Surprisingly, using ParallelTable doesn't speed up the calculation. I simply find almost the same computation time (not roughly a factor 8 difference)!

Can anybody explain to me what the reason for this is? I've tested the ParallelTable with commands like

  ParallelTable[Pause[1]; f[i], {i, 4}] // AbsoluteTiming


and for this case it works fine, but not for the NInverseFourierTransform.

ClearAll["Global*"];
f[q_] := Sqrt[2/Pi]*(-Sinc[q] + Cos[q]);
k[q_] := Sqrt[Pi/2]/Abs[q];
a = 10^-2;
b = 10^-2;
Needs["FourierSeries"]
hfourierdomain[ω_] = a*f[ω]*k[ω]/(1 + b*ω^2*k[ω]);
displ = Table[{j, NInverseFourierTransform[hfourierdomain[ω], ω, j]}, {j, -5, 5, 1/60}];

-
If you have a recent NVidia Graphics Card, you may use CUDAFourier which is much faster and easy to install/use. (May be there's nothing to install, I can't remember) – andre Jan 28 '13 at 20:47
@andre I think NInverseFourierTransform relies on NIntegrate internally, not on Fourier. It works on a numerical black-box function, not on a list of numbers. So CUDAFourier might not be useful here (it is of course a good replacement for Fourier) – Szabolcs Jan 28 '13 at 20:51
@Szabolcs Agree. I have Fourier[] and FourierTransform[] mixed up. – andre Jan 28 '13 at 21:05
Use ParallelNeeds[] for this. – Daniel Lichtblau Jan 28 '13 at 22:10

When I run your code on my machine with Table (not ParallelTable), I see that all the cores of the CPU are used by a single MathKernel process. This means that internally NInverseFourierTransform uses an operation that is already parallelized. Certain operations, such as LinearSolve, will be able to use all cores of your CPU even when run on a single kernel.
Because of this the Table version is likely already as efficient as it can be, and splitting the task into several parts and distributing it among kernels (which will individually all want to use all your CPU cores) is likely to just reduce performance.
@user5613 Also, sometimes parallelization doesn't speed up much computations because the problem is not broken into appropriately sized chunks. In this case manually tuning the Method option of Parallelize may help (but this doesn't apply to your particular problem). I couldn't get Outer to speed up the other day ... (with Parallelize --- there's no ParallelOuter, but Parallelize does work with Outer) – Szabolcs Jan 28 '13 at 21:06