[GRASS-dev] GRASS inefficiency and FFTW

[Glynn Clements]

Stefano De Paoli wrote:

> Then it was decided to use a library called FFTW (under GPL). The FFTW
> of course introduced a dependency, but this is not the issue. The
> decision to use FFTW introduced the following choices:
> 
> > requires either that existing applications are re-written to use the FFTW interface,
> > or that we add code to convert between the existing and FFTW interfaces (which 
> > might introduce inefficiency; I don't know the semantics of the existing interface,
> > so I can't tell).

> Now my questions.
> 
> Given this problem I started to wonder whether this example fit with
> the issue that Free Software is primarly about so called "freedom" and
> not about efficency. As many many Open Source advocates usually say.
> 
> Which means that an inefficient solution has been introduced in GRASS
> in order to maintain the integrity of the GPL license.
> 
> I had a mail exchange with Markus about this issue, and I suggested to
> him that the substitution of the Numerical Recipes FFT implementation
> in GRASS ended up with a not efficient solution.
> 
> Probably Markus won't accept my conclusion :-))
> 
> and maybe so do other developers
> 
> Of course one solution may be to rewrite the i.fft() so that it can
> access the FFTW directly without using the fft.c interface. But given
> the fact that this has not yet been done, the inefficiency still
> remains.
> 
> What do you think GRASS developers?
> 
> Is this an example of the fact that Free Software is primarly about
> freedom than about efficiency?

Yes; hence the term "Free Software" rather than "Efficient Software".

Of course, the two aren't mutually exclusive.

FFTW itself is free software, and it has substantially better
performance than the old NR FFT implementation (or just about any
other implementation in existence, AFAICT). The inefficiency is a
consequence of implementing a "minimal" change (preserving the
existing fft() interface) rather than an "ideal" one (modifying the
callers to use a more appropriate interface).

In terms of CPU usage, even the current implementation is more
efficient than the original version; the overhead of padding and
copying the data is easily outweighed by the improved performance of
FFTW. The inefficiency occurs in terms of memory consumption.

-- 
Glynn Clements <glynn at gclements.plus.com>