forums.silverfrost.com

[mecej4]

Here is another instance of an optimization bug. This one occurs when array sections are copied and /opt /64 has been requested. The bug is rather fragile, and minor changes to the code make it disappear. To make the bug easy to notice, I made two copies of a single subroutine, which modifies an input 2-D array. The two copies are identical except for one line. The first version has, on line 64,

[mecej4]

Here is the second version of the subroutine. Put the two pieces together into a single source file, compile and run with /64 /opt, then with /64 alone.

[PaulLaidler]

Thank you for this report. I have logged it for investigation.

[PaulLaidler]

An initial investigation indicates that the fault lies with item 30 of the optimiser. So a temporary "fix" is to add /inhibit_opt 30.

The issue remains outstanding.

[mecej4]

Paul, where can we see a list of these "optimisation item"s? How many of these are there, and are they grouped into categories?

[LitusSaxonicum]

I agree with Mecej4 - it would be interesting to see what optimisations are performed, and which might simply be skipped.

It's a long time since I even attempted to use /OPT, as my codes run adequately fast without it, especially on my new computer that is considerably faster than the old one.

Eddie

[mecej4]

Incidentally, Eddie, I was also brought up with "subexpression optimisation" in my blood. More recently, I have been weaning myself from that habit, because (i) it makes the code less readable, as it always did, and (ii) these days, it usually makes the code slower as well.

The variables that are created for the purpose of holding many of these subexpressions are very short-lived and, if they are declared in the subprogram declarations section, the compiler ends up generating code that will be doing lots of copying to and from main memory. Left to itself, the compiler optimiser can do a better job of recognising and confining these variables to registers.

[PaulLaidler]

I will make enquiries.

[LitusSaxonicum]

Mecej4,

I think it may well be the case that common subexpression removal by an efficient and working optimization is probably better than doing it yourself, but surely, for readability it depends how you write it, doesn�t it? And that, in part, depends on the naming of the variables that hold the pre-calculated common subexpressions. 'm1' doesn't cut it for me.

One programmer whose work I admired always used �GASH� (British military slang (specifically from the Royal Navy and Royal Marines) for rubbish (garbage), or for something that is considered useless, broken or otherwise of little value, rather than any other definition) for such a variable, and when more than one was required, supplemented them with �GESH�, �GISH�, �GOSH� and �GUSH� if he had to, which wasn�t often.

As for me, I tended to prefer COEF with various other suffixes for the same job. (COEF_A, COEF_B etc)

In both cases, the readability seems to me to be enhanced rather than degraded.

Eddie

[JohnCampbell]

I looked at array sections in scrch1 and found:

v (:mp1, j) = v (:mp1, jcol) ! opt fails
v (1:mp1, j) = v (1:mp1, jcol) ! opt fails
v (:, j) = v (:, jcol) ! opt is OK

The first 2 may take a section copy of the array, while the 3rd might not.

for " v (:, np1) = v (:, np1) - fact * v (:, lcol) ",
I would usually replace it by the following:
fact = -eq (lrow, n)
call daxpy (mp1, fact, v(1, lcol), v(1, np1) )

As with mecej4's observations of compiler optimisation performance, it is now better left to the compiler to clean this up. ( most of my F77 wrapper approaches are no longer effective)

[mecej4]

[JohnCampbell]

I was more trying to identify which types of array syntax are failing, hopefully to assist with the bug identification
I also tried a 3rd option that used F77 wrappers, but it is not as clearly presented as the array syntax.

https://www.dropbox.com/s/tso7bfyhwxikh5l/tst_opt.f90?dl=0

[LitusSaxonicum]

The reason why it might make the code slower is that when you put a subexpression result in a named variable, that variable has to be assigned its value, then retrieved each time, rather than the compiler holding the result in a register for re-use.

Why the compiler can't recognise the single variable as a subexpression to hold in a register I don't know, which costs you only the code to assign it to a named variable, and then of course, it will probably be still retained in the cpu cache anyway, but there you are.

Of course, the common subexpression recognition in the compiler and how effective it is depends in part on (a) being able to recognise it in the first place, and (b) how far ahead is the lookahead, (c) how many subexpressions are dealt with, and of course, whether the compiler does it correctly.

Personally, I gave up on /opt when I got funny results, believing that they were the result of re-ordering, which is a well-known issue with optimising compilers (I am usually in the fortunate position of being able to detect a stupid result). If it is the result of a bug, then perhaps I did the right thing.

I still always do simple, straightforward hand optimization, and believe the idea that it slows things down is an urban myth, but that may be my own myth.

Eddie

[PaulLaidler]

The original bug on this thread has now been fixed for the next release of FTN95.