pdf: 600KB - Potsdam Institute for Climate Impact Research

64
Reduced computational efficiency
There is a view that, as a general rule, a declarative approach takes more computer processing
time than an equivalent procedural solution. Ecosystem models can easily become
computationally demanding if, for example, they have fine spatial resolution on a grid, they
include large numbers of interacting objects, or they need to be simulated many times for
parameter estimation or sensitivity analysis. It is therefore appropriate to ask whether a
declarative approach becomes impractical for such models.
If a model is implemented in a computer program by a human programmer, then there is plenty of
scope for that program to be highly efficient. There are optimised subroutine libraries and
algorithms that can be used for time-critical parts of a simulation, Various programming tricks,
such as the use of hash tables and techniques for handling sparse arrays, can be employed. And
models can be programmed to run on a distributed-computing or parallel-computer system.
In a declarative-modelling approach, however, the executable version of a model is produced
automatically, using one of two methods. The software capable of handling models expressed in
the language might have their own built-in interpreter: this appears to be the approach employed
in, for example, the Stella modelling environment. In this case, evaluating an equation involves
two levels - processing by the software package and processing by the language in which the
package is implemented - and this necessarily reduces computational efficiency.
Alternatively, the software might use a program generator to generate a program which is
equivalent to the one that a human programmer would have produced for the same model. In this
case, it is possible, but certainly not inevitable, that the computer-generated program will be less
efficient. It is possible because the program generator might be rather crude, or not programmed
to detect special cases that could be handled more efficiently. However, it is also possible that
the reverse is true. The human programmer might not have the time or the expertise to implement
computationally-efficient algorithms - many ecosystem research models are implemented by
research scientists or by research assistants with little training in computer science. In this case,
the generated program could well be more efficient - in some cases, significantly so, since it can
undertake optimisations that the human programmer might not think of, or be unable or unwilling
to implement. For example, the Simile program generator automatically takes variables to the
outermost loop wherever possible, whereas the human programmer probably would not do this
because it would significantly complicate the code.
There are two additional points that are worth making. First, it is worthwhile investing in
improving a program generator for a widely-used modelling language, because the investment is
recovered across many models. So we would expect the program generator for a modelling
language to gradually improve over time. This would be especially the case if the programgenerating
software is open-source (as opposed to a proprietary commercial), so that it could
accumulate the refinements and tools for handling special cases of a large community of
programmers.
Second, we could have several program generators. One could be for standard, single-processor
PCs. Another could be for a workstation cluster running Condor (a widely-used network
management system that manages the farming-out of a task across a cluster of workstations).
Another could generate code for a parallel computer. Thus, the same model could be initially
developed and run on a desktop PC, then run in a more powerful environment if required.
In conclusion, it is probably theoretically true that a hand-crafted program can be computationally
more efficient than an automatically-generated one. However, in practice the reverse may well
be true, and the this will become increasingly so as tools for handling declarative models
gradually accumulate better and better solutions.