wiki feedback

I propose to adjust the [wiki](https://github.com/clij/clij-custom-convolution-plugin/wiki) a bit:

> That trick works because real space convolution is very memory and compute expensive: You have to have as many memory addresses as the image size multiplied by the kernel size, if you do it all in one go on a GPU.

Not sure what you mean by that. Inplace discrete convolutions don't work AFAIK: as you slide the kernel over the image, you alter the neighborhood that is needed as input by a neighboring pixel. So one typically goes with a outofplace convolutions. In terms of memory, the naive approach requires as much memory as 2 times the image size (input and output) plus the size of the kernel. For e.g. 3D convolutions, there is a trick to accelerate the memory accesses by using a full place as temporary storage. But I'd consider this a implementation detail and not relevant to the discussion.

> Doing it in series on a single or few CPUs, it takes that many multiplication operations.

No idea what you mean here. Are you referring to sequential operations?

> As images and convolution kernels get bigger this quickly spirals way out of control.

I'd say, "As images and/or convolution kernels" as in practise first images get bigger. Then people try larger kernels on the images they just made bigger.

> So the FFT method reduces the complexity to a single multiplication operation between each pixel in the FT of the image and kernel.

I propose to write this out, e.g. like "So the FFT method reduces the complexity in operations and memory accesses to a multiplication operation between each pixel in the transformed image and the transformed kernel.

> So long as the expensive FFT is faster than the real space convolution, the FFT method is faster.

This is a problematic statement. The speed of the FFT transforms is not the only bottleneck you encounter. FFTs require temporary memory depending on the shape of your inputs. This can go up to 3-4x times the input signal (that is at least the case for cufft). An FFT is basically a reduction operation. They are bound not by the computing speed of your hardware, but by how well/fast your cores can access memory. Further, the multiplication operation has a fixed complexity which is much lower than the one for a discrete convolution. But the former requires the transforms first.

> However, if you had a GPU with terabytes of RAM, and many thousands of parallel compute units, the real space convolution could be faster then the FFT trick, even for reasonably large sized images as we get in biology.

I personally wouldn't make this claim without backing of measurements. I didn't a benchmark 4-5 years ago on a Kepler server GPU. There, discrete convolutions of radius=1 (so 3x3x3 kernels of float32) were performing just as well as an FFT based convolution irrespective of the size of the input image. Anything larger than radius=1, did favor the FFT convolution.