Re: LDD/STD Optimizations

In article 92-03-041 preston@dawn.cs.rice.edu (Preston Briggs) writes:
> do J = 1, L
> call SGEMV(M, N, A, IA, B(J, 1), IB, C(1, J), 1, JB)
> enddo
>
>But the argument C(1, J) is specifying a column in a matrix. Is the
>column aligned to double words? You can't tell unless you know the length
>of C's 1st dimension.
>
>I expect that in a fair percentage of the cases, C will be declared to
>have an odd-sized 1st dimension. Not because the programmer using the
>library was stupid, but because that was his problem size.


But if you document the fact that this kind of code will run faster if the
leading dimension is even, then the "people who are seriously concerned
about performance" will change the leading dimension of their arrays to
take advantage of that.


In fact, if this code is being run on a vector machine then it is almost
certain that the programmers have gone out of their way to make the
leading dimension *odd*. (Really it isn't that hard in most code, just
change the dimension statement.) That is the stride of accesses to the
rows of C, and if C is ever accessed in that way it needs to be odd for
best performance.


If the programmers are willing to make the leading dimension odd for best
performance on a vector machine (and I know for a fact that many do), why
would they not be willing to make the leading dimension even for best
performance on the LDD/STD machine?


If you still don't like this, here's another optimization idea which
doesn't require any cooperation from the user. On entry to a module, copy
any unaligned arrays to known alignment, and on exit copy them back. (Of
course, you want to try to make sure that there is enough work in the
module to make this worthwhile, but there often would be.)


David desJardins
--

Return to the comp.compilers page.
Search the comp.compilers archives again.