Mail Archives: djgpp/2001/02/07/14:38:44

X-Authentication-Warning: broeker owned process doing -bs
Date: Wed, 7 Feb 2001 18:45:02 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Function and File ordering and speed optimization
In-Reply-To: <>
Message-ID: <Pine.LNX.4.10.10102071824070.4137-100000@acp3bf>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Wed, 7 Feb 2001, Eli Zaretskii wrote:

> > Date: Wed, 7 Feb 2001 16:08:53 +0100 (MET)
> > From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>

> > I think it only is going to make a noticeable difference if the active
> > code set is already very close (within a few 4KB pages) to the amount of
> > free memory. In such a situation, reducing the memory footprint might
> > indeed help to avoid paging altogether, and thus speed up things. But I
> > doubt there are enough programs that fulfill these conditions to be worth
> > bothering about this type of optimization.

> So you are saying, in effect, that improving locality of data
> accesses, like accessing a 2-dimensional matrix in the order of
> storage, is a waste of effort?

Code and data have different memory access patterns (and they're cached
separately, in the first caching level(s)). The idea behind linear access
patterns to large memory blocks is to do everything that has to be done to
a given memory page in one go, so once it gets paged out to virtual
memory, it won't have to be paged in again, anytime soon. 

In almost all situations I can imagine where optimization is worth
bothering with, there's much less code than data in the active set of a
program. Code tends to be used in much smaller loops than data, even more
so if it's really speed-critical code. Repeated used means that the memory
pages used by the critical code will hardly ever reach the bottom of the
LRU stack and thus be paged out in favour of others.

> > Let's face it: once the system starts to page stuff in and out on a
> > somewhat regular basis, all optimization is moot.
> All optimzations are moot, except those optimizations which make it
> page less.

Fully agreed. But for function ordering to avoid a significant fraction of
paging activity, it'd have to hit a rather small target, and essentially
by randomly shooting in its general direction. The memory footprint has to
be very close to the paging threshold for the few 4K pages it can possible
save you to have any drastic effect.

I.e. if you're randomly jumping around across exactly 31.9 MB of data,
actively using about 100K of code doing so, a machine with 32.0 MB of
memory (after setting aside space for the OS and other stuff) will start
paging wildly. Reducing those 100K of code by 8K might then allow to avoid
the paging altogether. But fluctuations in the size requirements of the
code and data, and especially the OS's memory footprint are rather likely
to be larger than those 8K, killing the effect or at least reducing it

So function ordering can avoid paging, but several other factors, some
completely uncontrollable by the program itself, have to behave nicely to
allow that effect to be stable. Most of the time, they won't.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019