trl@cbrma.UUCP (Tom Lanning) (06/24/86)
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"), any hope of keeping heavily used routines together in the same page would result in wacky source arrangments. If "true" hidding of implementation is done then nothing can really be done to group the functions so paging is minimized. Does anyone have any input on this subject? Are there things that I can do with/without C++ that would aid performance on a paging OS? Any comments or suggestions are invited. -- Tom Lanning AT&T Bell Laboratories Columbus OH 43213 614-860-4153
mat@mtx5a.UUCP (m.terribile) (07/03/86)
> > 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) ,.. .,, ,,, ..,***_*.