barmar@kulla (Barry Margolin) (10/28/89)
[Note that I've directed followups to comp.lang.misc, as this no longer seems to be about Ada.] In article <4697@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >In article <800@philmtl.philips.ca> pedersen@philmtl.philips.ca (Paul Pedersen) writes: >>The conclusion I came to was that it is not possible to do profiling >>using UNIX on a fast processor, short of using a logic analyzer and a >>lot of interpreting software (far from sure that this is even feasable). >>I would be *very* interested in hearing from anybody who has solved this >>problem (I gave up) :-) >Gee, I implemented profiling on this Unix machine in an afternoon. >Admittedly, I was helped by the existence of a system call 'profil', >which does all the real work. > >The purpose of profiling is to find out where the program is spending >a lot of its time. Now, the profiling command samples the program >counter 100 times a second, so in a one-minute run that is 6000 >samples. Any subprogram body that consumes more than 1% of the mill >will therefore generate on average more than 60 hits, which is surely >a meaningful number. This is called "statistical program counter metering" on the system I use (Symbolics Lisp Machines); until last year it was the only metering facility provided by Symbolics. They implemented it using microcode microtasks (Symbolics 36xx machines can run up to 5 concurrent microtasks) rather than interrupts, so the overhead is virtually nil and it samples very frequently. To be most useful, statistical PC metering should permit you to specify the frequency, particularly if your application contains loops (how many significant applications don't?). This is because the period of the loop might be close to the period of the PC sampling, and you would get distorted data. A way to get more precise metering is to make use of a trap-on-call/return facility. This can be implemented in hardware (as on the Lispm) or in software (the subroutine calling sequence could check a flag), or in the compiler (an option to the compiler tells it to generate metering code). Whenever a function call is made the trap handler records the time, and when it returns the elapsed time can be recorded. To get more precise timings, of course, you need a more precise clock; what you need is an independent high-frequency clock chip that can be read, rather than a clock that simply interrupts the processor every Nth of a second. Symbolics machines have a 60th-of-a-second interrupting clock to drive the scheduler and time-of-day clock, and a separate microsecond clock that can be read on demand (there's also a third clock, called the calendar clock, running in the front end processor, for use when Lisp is shut down). Another way of metering is to just count the number of times particular functions are called. This can be done using the same mechanisms as the above, but it doesn't require the high-frequency clock. Instead of reading the clock, the trap handler just increments a counter for the function being called. This is often useful for determining where the likely hot spots will be. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar