[GRASS-dev] GRASS inefficiency and FFTW

[Daniel Calvelo]

Hi Stefano, see below

On 2/26/07, Stefano De Paoli <dplsfn at yahoo.it> wrote:
> Dear GRASS Developers
>
[skip]
> 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?

I think you need to take into acount in your analysis the constraining
scarce resource within several FLOSS projects: motivated manpower. WRT
FFT, the current implementation is efficient in development cost,
although inefficient at runtime wrt to the NR illegal implementation.

>From a development (or software engineering) point of view, current
fft-based modules have respected interfaces of both upper-level
original modules and lower-level librairies, to avoid rewriting
substantial parts of each or both. The runtime efficiency is rather a
consequence of backward-compatibility and least intrusion (hence least
effort) than principles. The elegant and costly solution is to rewrite
the modules using FFTs to use FFTW.

A similar case can be made for the current status of v.in.ascii with
large datasets and the topology-building problem. The elegant and
costly solution is to reimplement the topology builder to use
space-bound algorithms. Non-trivial. Scalability in general is an
issue in GRASS.

> Would you agree with my conclusion?

Insofar as you introduce a notion of pragmatism in the achievement of freedom.

OTOH GRASS is atypical FLOSS because of its age and lineage. The entry
barrier for a GRASS developper is higher than that of many other FLOSS
projects because (i) the codebase is huge (ii) the original system
design (C, shell, file system as common storage, processes as basic
work-units, memory management by the OS) is unlikely to attract
"modern school" programmers (iii) some familiarity with GIS is
necessary. These are some of the characteristics that made the
GRASStep project dead on arrival IMO. It's also a substantial argument
in the on-going discussion about GAL (formerly known as GRASS-TNG).

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.

> Stefano

Daniel.

-- 
-- Daniel Calvelo Aros