Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site utastro.UUCP Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!ut-sally!utastro!nather From: nather@utastro.UUCP (Ed Nather) Newsgroups: net.unix Subject: Re: prof question Message-ID: <73@utastro.UUCP> Date: Wed, 1-Feb-84 10:33:13 EST Article-I.D.: utastro.73 Posted: Wed Feb 1 10:33:13 1984 Date-Received: Tue, 7-Feb-84 10:14:09 EST References: <16172@sri-arpa.UUCP> Organization: UTexas Astronomy Dept., Austin, Texas Lines: 29 <> From: Doug Gwyn (VLD/VMB)Profiling samples one's process every so often (clock tick typically) and records where the PC (program counter) is each sample. * * * * * - Since the sampling is periodic it may not be representative of the real PC distribution due to beating with code periodicities (especially if code and sampling are driven by the same clock); - Because the code is sampled rather than exhaustively traced, some sections can be missed, and in general Poisson sampling statistics apply (i.e. sampling error for a bin is roughly the square root of the bin count). I must disagree about Poisson statistics -- in fact, the first quoted point above explains beautifully why they *don't* apply. The basis of Poisson statistical description is that the population from which the sample is drawn (in this case, the times spent by the program in its various parts) is randomly distributed in the sampled parameter. If beating occurs this assumption is seriously violated. True, the "central limit theorum" says if you sample non-random stuff for long enough it begins to look random, but my experiences with "prof" suggest the effects are more erratic than random. With random distributions statistical predictions are possible. With erratic ones, you're on your own -- and good luck! -- Ed Nather ihnp4!{ut-sally,kpno}!utastro!nather