Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!tektronix!orca!frip!andrew
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.unix.wizards
Subject: Re: GNU OS suggestion -- memory "advice"
Message-ID: <3496@orca.WV.TEK.COM>
Date: 5 Jun 89 19:46:16 GMT
References: <1343@marvin.Solbourne.COM>
Sender: nobody@orca.WV.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 31

[]

	"Programmers can often predict what areas of a program or
	chunks of data space are going to be used more often than
	others, yet there is generally no way for the programmer to say
	that a chunk of code is or is not needed often, or is only
	called at a point at which speed is not critical."

Some research in the 1970s, when demand paging was new (to many of us),
suggested that programmers cannot do as good a job as they think they
can in predicting memory access behavior.  In general, totally
uninformed, dynamic LRU memory migration was found to win over
extensively tweaked, programmed memory migration.  (This was reported
in a CACM in about mid-decade; sorry I can't quote chapter and verse
from memory.)

	"In one case, a developer described a case in which a large
	array was being scanned a number of times in both row-major and
	column-major order.  He noticed that the slowdown came in the
	latter case since the OS was paging his data in an inefficient
	manner."

Well, sure; in column-major order (assuming a non-Fortran language),
the program is stepping to a new page much more often than in row-major
order.  If a single row is a page or more in size, column-major order
will touch a new page with every single index iteration.  No amount of
memory advise to the OS can mitigate the result of this pathological
behavior.

  -=- Andrew Klossner   (uunet!tektronix!orca!frip!andrew)      [UUCP]
                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]