Parallelization with FTN95

John

If you would like to post a sample calculation I would like to take a look at it when I can. I don't know when that will be but if I had your code to hand I might be able to find a minute to look at it.

Paul,

Thanks, I will review some of the emails I sent in 2002 and see if I can summarise a later one that still identifies the problem and email it in a cleaner form. It is useful to look at these emails after time and see how (un)clearly I described the problem.

Typical of the problems with in-line expansion of dot_product x = dot_product ( a(i1:i1+n-1), b(j1:j1+n-1) )

is a fairly good example of when compilation with /debug produces a poor solution. Even replacing this by an intermediate call,

x = vec_sum ( a(i1:i1+n-1), b(j1:j1+n-1) ) or (f95) x = vec_sum ( a(i1), b(j1), n ) (f77)

where vec_sum is only a call to dot_product produces a much better result.

Also, I saw your comment on selective omission of optimisation. Lahey had something similar, but I never found it useful. It became difficult to be able to selectively use and remember which parts of the code could cause what problems. When my programs have many files, I do use different compilation options (in .bat files), being: /check for data reading and reporting /debug for most code and /opt for routines that are stable and use a high proportion of the run time. I do have vec_sum compiled with /opt in my library file.

I would like to see automatic implimentation of /opt in 'safe' code areas, such as:- array functions like dot_product and do loops where there are no unusual exits, such as calls to subrotines or non-pure procedures I suppose what I am saying is I'm lazy and I want you to put the effort into improving optimising, rather than me trying to understand what optimisation approaches give me trouble.

John

There is a lot of opmisation that is carried out by default. /opt provides extra optimisation that could be less safe in certain extreme circumstances.