Silverfrost execution speed?

Hi community,

I've 2 question,

1. I'm trying to run a moderate linear(to be specific 2628 equations) algebraic problem solution, based on Gauss elimination. The solution phase is taking approx. 4-5 min. The global matrix is not optimized, so that means 2628x2628 global matrix in size, and I didn't play around with any configurations in Project settings. Even though I did have such a impediments, is it normall to have such an execution time for moderately large algebraic systems ?

2. What happens if I define something like that :

   allocate ( loading(neq) ) ... .... variable = loading(0); ..... ....

Normally this should have thrown exception about 'Out of Index Error' but compiler returns the smallest value (e.g. -1e-302 ) depending on the selected real kind parameter definitions. If we leave aside the exception issue, I would expect it to return 0 for not defined values.

Is this also an expected behaviour ?

Regards,

I cannot comment on item 1 but for item 2 you should think of using CHECKMATE when testing.

Thanks,

That checkmate drastically increased the execution time from 4-5min to 9-10 min, at the end of it throwed the exception right at the expected line variable = loading(0); So that didn't help me heuristically,

Any other comments especially regarding the 1st item will be appreciated. I basically couldn't grasp, whether that amount of data (2628x2628 matrix) is more than can be handled by computer or not.

IMHO it shouldn't be a problem at all, when it's compared to all that stuff computer is performing with e.g. OpenGL, DirectX etc.. per frame, per second operations. But it seems that it doesn't turn out to be like that .

Regards,

Using Checkmate will be slower because it has to check lots of things as the code is running. You knew about the 'out of bounds error' before and the run time checking has confirmed that this problem exists. Furthermore, you know there are no other out of bounds errors (or other errors) up to that point, which should be comforting.

You would not keep Checkmate enabled when you deploy your code or use it to do the calculations you want; it is only used during development, testing and debugging. You can also turn on some optimization flags when you compile for deployment.

Your matrix is fairly big to factorise. The time you quote is small compared to (say) doing the same thing in python or basic. You can get compiler that generate faster code that Silverfrost FTN95, but it one of the best available for run-time checks.

Ronan,

4-5 minutes sounds a bit slow. I'm not sure what you mean by 'Gauss elimination', or where you obtained your solver. This can be a general name for direct solution of linear equations, as apposed to an itterative solution. Changing the solution so that you use vector calculations, like Dot_Product ( A(:,i), A(:,j) ) will improve the performance. You could consider the Cholesky Crout algorithm, which is defined as colum based algorithm and suits vector syntax. Is your matrix symmetrical, or even well behaved ? These considerations could speed up the performance. Most FE solvers utilise symmetry and banding/profile to improve performance, although you did say the matrix is not optimised. This saves storage and time by ignoring lots of zero's. There is a huge amount of work on equation re-ordering to reduce the matrix profile, but even a simple connectivity tree analysis of equation ordering can be a big help. If you have to solve a non-symmetrical matrix, requiring pivoting to control accuracy, then the solution time will be slower. There are many public domain solvers out there, that take advantage of some aspect of the equation set. How many times are you going to solve these equations ?

John

John's reply is basically: 'use the right algorithm'. That can speed up your run times enormously. If your matrix is sparse or banded, then it is possible that you are doing many unnecessary operations on zeroes.

Your array comes out (using REAL*8) at around 55 megabytes, which is tiny relative to today's RAM in a Windows machine. You may be happier just getting a faster machine to run it on - unless you value your time as worthless, the fastest PC you can buy, updated every 6 months, beats the costs of significant reprogramming.

While FTN95 doesn't generate the fastest executables, it does a reasonable job, and it has many other plus points.

It is also possible that you have programmed your application in a non-optimal way. There are books on this topic.

Sometimes, however, the run times can't be improved by much. Have patience. In the future they will be shorter. In my case I have seen drops from 3 hours to 30 minutes on a mainframe by recoding, and from 17 hours to 20 minutes by buying a faster PC. The original code (the one that took 3 hours) now runs in less than 1 second on a PC, with graphics - but I did have to wait 40 years for the technological advances to take place!

E