[GRASS-dev] GRASS inefficiency and FFTW

[Glynn Clements]

stefano de paoli wrote:

> What if GRASS would have been released under a license
> compatible with the Numerical recipes copyright?
> (I'm not sure whwther such a license exists)
> 
> Probably, in such a situation the development cost
> argument conclusion would be that the Numerical
> Recipes would still be in GRASS.

Unless someone found a bug in the code, or it failed to compile under
a newer version of GCC, failed to compile on 64-bit architectures,
etc. The decision to switch from the NR code to FFTW was "provoked" by
the licensing issue, but it could realistically have occurred for
other reasons.

A comparison of the NR code vs FFTW on their own merits would have
strongly favoured FFTW; consequently, as soon as any non-trivial issue
arose with the existing code, a switch to FFTW would have been a
likely result. The licensing issue just happens to have been the
trigger.

> I still support the conclusion that there is an
> inefficiency which heavily dependes on the GPL choice.

The decision to switch FFT implementations due to licensing was
certainly a factor. The decision to only expend the bare minimum of
effort to get the FFTW version working had nothing to do with
licensing, though.

If you study enough of GRASS' history, you will find very similar
issues arising from reasons other than licensing, e.g. Windows
compatibility or the changes to the vector architecture.

E.g. my recent changes to v.digit only involved the bare minimum of
work required to replace the use of libraster with a Tk canvas. The
v.digit code wouldn't look anything like the current version if it had
been written to use a Tk canvas from the outset.

Similarly, the structure of the display architecture has a great deal
to do with graphical terminals (Tektronix 4105 etc). And the display
architecture is relevant to a lot more users than the handful of
modules which use the FFT code.

IOW, classifying cases of "inertia-related inefficiency" according to
what triggered the underlying changes isn't a meaningful exercise,
IMHO.

> > To support your argument, I would rather investigate
> > the cases of both
> > Harmony projects (the first was a clean-room
> > reimplementation of the
> > Qt toolkit under a free software licence; the second
> > idem for Java)
> > and especially the whole Java situation. Debian
> > discussions wrt to
> > Java and the java trap could be a good source.
> 
> Basically I'm not trying to support the argument that
> there are many situations where freedom matters are
> more important than "efficiency".

Right; because the FFT issue doesn't really support that. When the
switch to FFTW was discussed, efficiency (in terms of memory usage)
really wasn't a major factor. The main factors were the amount of
developer effort required to make the change and the addition of FFTW
as a dependency.

If we had been particularly concerned about about efficiency, changing
a handful of modules (i.fft, i.ifft, r.surf.fractal, i.zc) wouldn't
have been a major issue (the changes to the build architecture to
handle FFTW as an optional dependency, fftw.h vs dfftw.h, and FFTW 2.x
vs 3.x have required significantly more effort).

Actually, if we had been particularly concerned about efficiency, we
would have gotten rid of the NR code earlier. Aside from the excess
memory consumption, FFTW is faster. And on the grounds of memory
consumption, the NR code *requires* that you use up to four times as
much memory as is actually necessary (the algorithm can only hande
power-of-two array dimensions). The existing inefficiencies are only
there because (so far) nobody has cared enough to eliminate them.

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