On Wednesday, 1994-07-20  Jonathan de Boyne Pollard wrote to Donald
Macmillan about "DA/2 Distributed Applica" as follows:

JP> DM>
JP>   > We have improved the OS/2 code but it still runs 32% slower
JP>   > than DOS.
JP> DM>
JP> 
JP>   OK, let's think this out logically.  You have, in your words, a
JP>   totally CPU bound program (no I/O whatsoever), which is running at 2/3
JP>   of the speed of the DOS version of the program.
JP> 
JP>   Assume that this is the same code for the moment.  OS/2 doesn't
JP>   consume 1/3 of CPU time in timeslicing, yet exactly the same code
JP>   executes at vastly different speeds both with and without timeslicing.
JP> 
JP>   Clearly one of the premises is in error.  Well from experimentation it
JP>   isn't the premise about the timeslicing overhead.  Therefore it's the
JP>   assumption that you have the same code on both platforms.
JP> 
JP>   Since you've as much as said that you hired an extra body to do the
JP>   OS/2 port, one can conclude that this is much more likely.  Your
JP>   programmer either made a mistake in porting your code, or used an
JP>   inappropriate algorithm for multitasking virtual memory work (such as
JP>   access to multidimensional arrays in minor/major order).

Hi Donald,

I think Jonathan is right.

I detect the aroma of FORTRAN. This is very reminiscent of mainframe
FORTRAN programs when transitioned from the IBM System/360 to the
System/370, about 20 years ago. (I remember because I have been
writing FORTRAN for that long.) The problems were due to execssive
page faults, because FORTRAN programmers, by and large, did not
understand virtual storage. (The 360 was a real storage machine and the
370 a virtual storage machine.)

The underlying fault (no pun intended) is in the design of the FORTRAN
language semantics -- storing matrices in column-major order, instead
of row-major order. Most programmers access the matrix elements inside a
DO loop nest in row-major order, beacuse most algorithms are specified
that way. However, because FORTRAN stores them in column-major order,
each successive element access of a large array will occur on a
different page frame, increasing the probability of a page fault.

Thus the code:

       DIMENSION X(4000,5000)
           .
           .
           .
       DO 10 I = 1, 4000
          DO 20 J = 1, 5000
           access X(I,J) in some manner
   20     CONTINUE
   10  CONTINUE

will run slower than:

       DO 10 J = 1, 5000
          DO 20 I = 1, 4000
           access X(I,J) in some manner
   20     CONTINUE
   10  CONTINUE

The latter will run faster because it runs down each column of the
matrix most rapidly and so adjacent storage locations inside the array
X will be accessed in successive iterations. As the size and
dimensionality of the array increases, so does the performance hit.

In languages that store matrices in row-major order the reverse is
true. Code analogous to the first will run quicker than code analogous
to the latter. However, in years gone by, FORTRAN was the major
culprit, as exhibited above, because of the habit of running across
rows instead of down columns.

Regards

Dave

___
 X KWQ/2 1.2e X When it comes to paradigms, shift happens...
--- Maximus/2 2.01wb