Anonymous user
Talk:Multi-dimensional array: Difference between revisions
→Column-major order in Fortran
| (3 intermediate revisions by the same user not shown) | |||
Line 166:
:::Some array elements were for "between" other array elements as with fence lengths and fence poles. The idea was to encourage the compiler to recognise equivalent indexing. I hadn't extended this to array R though when I abandoned further effort. My next ploy would have been to consider equivalencing the two-dimensional arrays to one-dimensional, to take advantage of such details as R(I - 1,J) being 40 elements away from R(I,J), though my earlier changes had reduced the frequency of such offset accesses so that delicate testing would be required for assessing any speed changes. Oddly, I had found that the optimising compiler produced code that ran slower than unoptimised.
:::So, I've been wondering about mentioning that n-dimensional arrays can be equivalenced to m-dimensional arrays... [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 11:47, 27 October 2016 (UTC)
::::Regarding elapsed time: it's not relevant. Use SYSTEM_CLOCK or CPU_TIME, and you will get a ratio of 10 (and even 20 with Intel Fortran, the other one was GNU Fortran). The problem is, using a row-wise algorithm in Fortran, there are many cache misses, thus the CPU waits for data. Of course it's not "pure CPU time", but such a measure would be totally useless: when working with large data, the memory pattern of your program has a big impact, it's not just a matter of CPU cycles (you can use "cache touch" machine instructions to load before you compute, but it will always be much faster with contiguous data). By the way, the code I wrote above is almost exactly an LU decomposition (the second one was copy-pasted from two subroutines doing the LU decomposition for the first, and solving the two triangulat systems for the second). Gaussian elimination is more or less the same thing as an LU decomposition.
::::Of course, permuting loops invloves changes to the body of the loops. This is part of algorithm design, not implementation.
::::
::::Regarding FORALL, the interpretation is relatively simple, as with other array statements and functions introduced by Fortran 90: never rely on side effects, hence evaluate all right-hand side values before any assignment. This would involve allocating temporary storage and copying in a rigid interpretation of this rule. In many situations, however, the compiler is able to do better than that. FORALL is indeed useful only when the result does not depend on the evaluation order. Anyway, given the ability of modern compilers, I don't regard FORALL as very usueful, but see also [http://stackoverflow.com/questions/8602596/fortran-forall-restrictions here] and [http://stackoverflow.com/questions/4122099/do-fortran-95-constructs-such-as-where-forall-and-spread-generally-result-in-fa here].
::::[[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 16:13, 27 October 2016 (UTC)
| |||