[Help-gsl] How to efficiently use temporary vectors and matrices

[Boris Langendoen]

Hello,

I am trying to implement a realtime version of a kalman filter for the 
navigation of my universities unmanned helicopter project.

One of the requirements is a 100Hz realtime update rate so some 
efficiency is necessary. I prototyped the filter in octave/matlab, and 
it is running at about 6ms per update on my development pc (under 
Octave/GNU/Linux).

The control computer runs under QNX, and all our realtime code is ANSI 
C, so now I am attempting to move my filter code to C. I am trying to 
use GSL as the library, and hope to arrive at about 1ms per update (so 
that the control code etc... has some time left to do its thing).

The problem I have, is that I have written several functions, each of 
which needs a number of 'temporary' matrices and vectors to do its 
internal calculations. These matrices and vectors' sizes can be computed 
 when the filter starts, and remain fixed during runtime. The values of 
the elements are not always constant.

If I follow the examples from the gsl documentation, I see only two 
options to create these temporary matrices within my functions.

Either (re-)allocate all the temporary matrices each time I call a 
function, fill them with the required values and then use them. I have 
been told this is not very fast, and looks unnecessarily complex to me.

Or allocate all the temporary matrices when the filter starts (during 
the startup routine), and pass them as arguments to the functions. This 
should make the code fast in the sense that allocation / deallocation 
will not have to be done so often, but is also complex as all the 
temporary matrices are declared and allocated somewhere outside of the 
calling functions (at the moment I need 37 temporary matrices and 27 
temporary vectors in total). It also looks like quite hard to debug.

I would like to know if I missed some (perhaps obvious) solution to this 
problem. I am not a computer science student so I have no formal 
training in the field.

Many thanks,

Boris Langendoen,

MSc student, Control & Simulation Division
Faculty of Aerospace Engineering
Delft University of Technology
The Netherlands