Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!lloyd!cprice From: cprice@mips.COM (Charlie Price) Newsgroups: comp.arch Subject: Re: Page size and linkers (was: Re: SunMMU history) Message-ID: <45757@mips.mips.COM> Date: 10 Feb 91 23:45:24 GMT References: <45242@mips.mips.COM> <1991Jan27.214522.24408@watdragon.waterloo.edu> <1991Jan29.033024.1516@craycos.com> <1991Feb4.190949.1190@HQ.Ileaf.COM> Sender: news@mips.COM Reply-To: cprice@mips.COM (Charlie Price) Organization: MIPS Computer Systems, Inc Lines: 96 In article <1991Feb4.190949.1190@HQ.Ileaf.COM> md@HQ.Ileaf.COM (Mark Dionne x5551) writes: > >I have done some experiments with Interleaf (a large publishing program >written in C), and found that for many usage patterns, typically about 25% >of the code that is paged-in is actually touched. This can mean that up to > >One thing that would help out here would be a compiler switch that would >produce multiple .o files for a single .c file (one .o file per function). >It would then be possible to set up an automated reordering scheme where >gprof output would be used to reorder the functions. (Static functions >would optionally be either coalesced or treated as global.) An ideal >candidate would be gcc. Any volunteers? MIPS has shipped this basic capability (in a slightly different form) for years. The MIPS' tool is primary used to rearrange routines during linkage so that the most active routines don't conflict with each other in the instruction cache. It lays them out sequentially from most active to least active (up to some limit) and this would achieve the effect you talk about. Here is how it works: cc -O -o gleep gleep.c produces gleep. Create (or find) the executable you are interested in... pixie gleep Create an instrumented version of the executable with pixie. The instrumented version, named OBJNAME.pixie by default, does the same function that the original program did, and also keeps statistics about what goes on inside the program -- in particular it keeps execution counts for basic blocks. Pixie also writes out a "map" file (OBJNAME.Addrs) that is needed to reconcile the basic block structure to program labels. gleep.pixie program_arguments... Run the instrumented program producing a statistics file named OBJNAME.Counts (here gleep.Counts). Multiple runs (with different inputs, for example), can be handled, but you must move the gleep.Counts file "out of the way" before each run. prof -pixie -feedback feedback_file_name gleep gleep.Addrs gleep.Counts... Process the gathered statistics file(s) (one or more X.Counts files) and produce a "feedback" file that can be used by the compiler system. The basic computation is to figure out which relocatable objects (functions) are used the most from the basic block count information. cc -O -o gleep.new -cord -feedback feedback_file_name gleep.c Recreate the executable, running the "cord" rearranger pass using the specified feedback file. As an aside, pixie is really for program performance analysis. Getting information for rearrangement was not the primary choice. For instance, you can discover which lines in a source program use up the largest number of cycles. prof -pixie -heavy glorp produces the following information: Profile listing generated Sun Feb 10 15:35:20 1991 with: prof -pixie -heavy glorp blkclr and bzero (bzero.s) synonymous: using latter -------------------------------------------------------------------------------- -- * -h[eavy] using basic-block counts; * * sorted in descending order by the number of cycles executed in each * * line; unexecuted lines are excluded * -------------------------------------------------------------------------------- -- procedure (file) line bytes cycles % cum % lwputstr (glorp.c) 1016 216 1632974 11.67 11.67 pfile (glorp.c) 754 76 1564005 11.17 22.84 pfile (glorp.c) 766 88 1354976 9.68 32.52 pfile (glorp.c) 753 44 1121371 8.01 40.53 pfile (glorp.c) 853 80 1121311 8.01 48.54 pfile (glorp.c) 762 40 741465 5.30 53.84 lwputstr (glorp.c) 1014 24 648692 4.63 58.48 lwputstr (glorp.c) 1019 20 538362 3.85 62.32 pfile (glorp.c) 761 32 342904 2.45 64.77 pfile (glorp.c) 849 72 336097 2.40 67.17 ... cut off here... -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650