|90/10 rule... source? email@example.com (Jens Troeger) (2004-01-09)|
|Re: 90/10 rule... source? firstname.lastname@example.org (2004-01-12)|
|Re: 90/10 rule... source? email@example.com (Derek M Jones) (2004-01-12)|
|Re: 90/10 rule... source? firstname.lastname@example.org (2004-01-16)|
|Re: 90/10 rule... source? email@example.com (Mike Kent) (2004-01-16)|
|Re: 90/10 rule... source? firstname.lastname@example.org (Derek M Jones) (2004-01-17)|
|Re: 90/10 rule... source? email@example.com (James Cownie) (2004-01-22)|
|Re: 90/10 rule... source? firstname.lastname@example.org (2004-01-22)|
|Re: 90/10 rule... source? email@example.com (Derek M Jones) (2004-01-31)|
|From:||firstname.lastname@example.org (Nick Maclaren)|
|Date:||16 Jan 2004 22:25:25 -0500|
|Organization:||University of Cambridge, England|
|Posted-Date:||16 Jan 2004 22:25:24 EST|
Derek M Jones <email@example.com> wrote:
>> I am looking for a (the) original paper on the 90/10 rule of program
>> execution. So far I found this reference
>I think the 90/10 rule might qualify as an urban legend.
>Example 8 of Knuth's paper quotes a 90% figure, but many of the
>other examples are around the 50% mark (a few 70%'s).
Yes and no. I think that the rule is real, but it has been made into
a pseudo law of nature, which it isn't.
>[I think the 90/10 rule comes from databases, where long before there
>were computerized files it was well known that in most record systems,
>a small set of records got most of the lookups. -John]
Could well be.
I first came across it (in the late 1960s) in the form that you get
90% of the benefit for 10% of the effort; in that form, it is a pretty
good rule of thumb. But, even so, it makes no sense if interpreted
too much like a formula.
Since then, I found evidence of it in previous centuries, in such
forms as maintaining discipline: 90% of the trouble comes from 10% of
the people. I don't know how old it is in that form, and can no
longer remember where I saw it.
As far as program tuning an optimisation is concerned, the lowest I
have seen is in things like statistical packages, where it is common
for the time to be spent in a large proportion of the code. In such
cases, cleaning up code and using a good, general, optimiser gives the
The highest I have seen is in a few HPC codes run on specialist
systems, such as one where 98% of the time was spent in two, 99.99%
vectorisable loops. The loops were hundreds of lines long with lots
of calculations, but every cycle could be done in parallel, and the
loop count was fixed at about 30,000!
Return to the
Search the comp.compilers archives again.