🚀 go-pugleaf

> 
> 	I am new at tuning software for a demand paging operating
> system, but it seems that heavy use of derived classes with virtual
> functions could really cause a decrease in locality of reference
> if each class is implemented in a single source file.  Since a
> function of derived class "C" calls functions implemented in class
> "B", (which uses some functions implemented in class "A"), . . .

Back in the days when (should I admit it?) I was working on an HP 3000, I
ran across some interesting recommendations.  The 3000 has a perverted
memory management and execution permission scheme, and it's easy slow the
machine down very badly.

You could, if you had the courage, edit the semi-linked libraries (USLs) to
change the segment layouts.  Our site received an irregular newsletter from
a performance consultant who specialized in that machine (and made a *lot* of
money at it!).  If he said that something was worth doing, it was worth doing.

One of his recommendations was to change this:

	Seg 1		Seg 2		Seg 3

	pr_rep		load_rep	check_rep
	pr_tot		load_tot	check_tot
	pr_head		load_head	check_head

into this:

	Seg 1		Seg 2		Seg 3

	pr_rep		pr_tot		pr_head
	load_rep	load_tot	load_head
	check_rep	check_tot	check_head

You will recognize this as being close to the sort of layout you get using
``simpleminded'' coding of class-structured C++ .

Which is to say that you're not doing too badly with it.

If you find a particular class has a couple of short-running and often-called
functions, you can try writing them to be placed inline.

Also, I wonder what you are trying to achieve.  If your goal is to have a
working set of 4 pages out of 40, or out of 400, only the grubbiest manual
diddling will buy you that.  You will have to structure the code around stimuli
rather than around properly abstracted data.  On the other hand, if your goal
is to have a working set of 14 pages out of 40, or even out of 400, I suspect
that you'll do *better* with C++ than with a naive implementation.


(Obligatory editorial follows)
I have to admit that I hoped that this topic had gone away forever.  Hand-
tuning a demand paged program seems to negate most of the benefits of the
DEMAND paging!  You might as well be doing segment overlays on RT-11.
It's also been established that there are lots of environments where demand
paging does *not* improve execution overall.  If you're short on disk I/O
bandwidth, and especially on disk head bandwidth, it's probably better to
just load the whole thing and let it rip.  Attempting to play working set games
can eat a lot of I/O.  If you're compute bound, and you are trying to serve
many users out of small memory, demand paging can make a lot of sense.

But before you play hand-tuneit, try it running naively.  You *might* be
surprised.
-- 

	from Mole End			Mark Terribile
		(scrape .. dig )	mtx5b!mat
					(Please mail to mtx5b!mat, NOT mtx5a!
						mat, or to mtx5a!mtx5b!mat)
					(mtx5b!mole-end!mat will also reach me)
    ,..      .,,       ,,,   ..,***_*.