X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Wed, 7 Feb 2001 18:45:02 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: Function and File ordering and speed optimization In-Reply-To: <2950-Wed07Feb2001191615+0200-eliz@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk On Wed, 7 Feb 2001, Eli Zaretskii wrote: > > Date: Wed, 7 Feb 2001 16:08:53 +0100 (MET) > > From: Hans-Bernhard Broeker > > 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 strongly. 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.