Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) Newsgroups: comp.arch Subject: Smart Linking Message-ID: <9557@pt.cs.cmu.edu> Date: 7 Jun 90 15:54:48 GMT References: Organization: Carnegie-Mellon University, CS/RI Lines: 32 In article Rick.Rashid@CS.CMU.EDU writes: >The runtime size of a lot of X programs (e.g. xterm, xclock, X, etc.) >varies strongly with the page size of the machine being used. >The easiest guess is that >what you are looking at is heavy internal fragmentation due to the >modularity of the code (most subroutines don't call other routines in >the same module but rather those in other modules), the lack of >an intelligent linker (which would figure that out and relocate routines) >and memory allocation routines which are not working set sensitive. Intelligent linking is a strangely unaddressed problem. There has been some work on this in the mainframe world - I recall articles in the mid-70's, in the IBM Systems Journal (or IBM JRD?). But, I don't recall any Unix products. Most OSes don't want you to know what pages were in your working set, much less the order of the page faults. Of course, good information could still be gathered at the user level, using the calling-convention techniques of "prof" and "gprof". This isn't a silly concern. In a former life I speed-tuned my company's product, some 600 KB of code. It was clear to me that Unix's "ld" was giving me dumb results. For example, there were 350 init routines that were only called on startup, but placing them together was so hard that I didn't do it. Sounds like a job for OSF ... or someone battling the SPEC wars ... -- Don D.C.Lindsay leaving CMU .. make me an offer!