Path: utzoo!attcan!uunet!dg!rec From: rec@dg.dg.com (Robert Cousins) Newsgroups: comp.arch Subject: Re: Smart Linking Message-ID: <510@dg.dg.com> Date: 8 Jun 90 15:12:01 GMT References: <9557@pt.cs.cmu.edu> Reply-To: uunet!dg!rec (Robert Cousins) Organization: Data General, Westboro, MA. Lines: 46 In article jeremy@cs.ua.oz.au (Jeremy Webber) writes: >In article <9557@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > > 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. > > [ observations about page sizes and smart linking ] > >Of course, if the X libraries have been made sharable (which they should on >a machine which supports shared libraries) it becomes harder to allocate more >than one module to a page. It's still worth persuing though on machines with >large page sizes though. Does anyone's linker handle this situation neatly? >Jeremy Webber ACSnet: jeremy@chook.ua.oz >Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au >60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430 >Australia Papernet: +61 8 272 2774 (FAX) Actually, the issues of optimal linkage editing and shared libraries, while similar in effects, offer additive opportunities for substantial improvement in performance. Lets talk about linking first. Most machines have large enough caches (or multiple set caches) to allow more than one routine to be resident at a time. An intelligent linkage editor should look at the call-tree and assign routines to addresses such that whenever possible, routines which call each other do not flush the other out of the cache and furthermore, that the placement of these routines reduces the TLB thrashing which is becoming more common as text areas increase. There have been papers written on this subject. The problems with shared libraries are two fold: many developers hate to use them because they increase the *perceived* support burden since different vendors may supply different libraries with subtle differences known as *bugs*. The second problem is that large libraries (such as some widget libraries) which require large amounts of space ("hello world" with OSF/Motif is almost 1 megabyte on my 88K machine) are either not offered or designed for use in a shared library format. To address this problem, ABIs and BCSs must specify the nature of shared libraries and provide viable certification tools. Shared libraries will not, however, reduce the memory requirements for data space which many of these libraries require in large quantities. Robert Cousins Dept. Mgr, Workstation Dev't Data General Corp. Speaking for myself alone.