Performance question: Inverting an array of pointers in-place vs array of values

The background for asking this question is that I am solving a linearized equation system (Ax=b), where A is a matrix (typically of dimension less than 100x100) and x and b are vectors. I am using a direct method, meaning that I first invert A, then find the solution by x=A^(-1)b. This step is repated in an iterative process until convergence.

The way I'm doing it now, using a matrix library (MTL4):

For every iteration I copy all coeffiecients of A (values) in to the matrix object, then invert. This the easiest and safest option.

Using an array of pointers instead:

For my particular case, the coefficients of A happen to be updated between each iteration. These coefficients are stored in different variables (some are arrays, some are not). Would there be a potential for performance gain if I set up A as an array containing pointers to these coefficient variables, then inverting A in-place?

The nice thing about the last option is that once I have set up the pointers in A before the first iteration, I would not need to copy any values between successive iterations. The values which are pointed to in A would automatically be updated between iterations.

So the performance question boils down to this, as I see it:

- The matrix inversion process takes roughly the same amount of time, assuming de-referencing of pointers is non-expensive.

- The array of pointers does not need the extra memory for matrix A containing values.

- The array of pointers option does not have to copy all NxN values of A between each iteration.

- The values that are pointed to the array of pointers option are generally NOT ordered in memory. Hopefully, all values lie relatively close in memory, but *A[0][1] is generally not next 开发者_JAVA百科to *A[0][0] etc.

Any comments to this? Will the last remark affect performance negatively, thus weighing up for the positive performance effects?

Test, test, test.

Especially in the field of Numerical Linear Algebra. There are many effects in play, which is why there is a number of optimized libraries that have solved that burden for you.

Some effects to consider:

• Memory locality and cache effects
• Multithreading effects (some algorithms that are optimal while running single-core, cause memory collision/cache eviction when more than one core is utilized).

There is no substitute for testing.

Here are some comments:

• Is the function you use for the inversion capable of handling a matrix of pointers instead of values? If it does not realise it has to do an indirection, all kinds of strange effects could happen.
• When doing an in-place matrix inversion (meaning the inverted matrix overwrites the input matrix), all input coefficients will get overwritten with new values, because matrix inversion can not be done by re-ordering the elements of the matrix.
• During the inversion process, none of the input coefficients may be changed by an outside process. All such updates have to be performed between iterations.

So, you get the following set of trade-offs when you chose the pointer solution:

• The coefficients making up matrix A can no longer be calculated asynchronously with the matrix inversion.
• Either all coefficients must be recalculated for each iteration (when you use in-place inversion, meaning the inverted matrix uses the same memory as the input matrix), or you still have to use a matrix of N x N values to hold the result of the inversion.

You're getting good answers here. The only thing I would add is some general experience with performance.

You are thinking about performance a-priori. That's reasonable, but the real payoff is a-posteriori. In other words, you don't know for certain where the real optimization opportunities are, until the running code tells you.

You don't know if the bulk of the time will be spent in matrix inversion, multiplication, copying the matrix, dereferencing, or what. People can guess. If I had to guess, it would be matrix inversion, because it's 100x100. However, something else I can't guess might be even bigger. Guessing has a very poor track record, especially when you can just find out.

Here's an example of what I mean.