OT: Plauger quote

[Chris Stiles]

Hi --

A while ago I remember reading a quote in one of Plauger's books that went
something like:

"Beware of tweaking what is measurable, rather than what's effacious"

The source given was an IBM service manual. Does anyone know the quote I
refer to ?

 

[Christian Bau]

Hi --

A while ago I remember reading a quote in one of Plauger's books that went
something like:

"Beware of tweaking what is measurable, rather than what's effacious"

The source given was an IBM service manual. Does anyone know the quote I
refer to ?

I wouldn't know where the quote comes from, but it is a common mistake.

For example, there are some "clever" people who try to write benchmarks
and find out that some benchmarks depend very much on the compiler used,
while others don't. So they throw away the benchmarks that are more
compiler dependent. The problem: Memory bandwidth limited benchmarks are
usually independent of the quality of the compiler, while everything
else isn't. So they end up measuring bandwidth limited problems only.

Not that bandwidth isn't important, but it is not the only factor.

(Or guess what would happen if your boss decided that you will be paid
per line of code written in the future - which is very easy to measure.
How many lines would you write to fill an array of 10000 ints completely
with zeroes? )

 

[P.J. Plauger]

A while ago I remember reading a quote in one of Plauger's books that went
something like:

"Beware of tweaking what is measurable, rather than what's effacious"

The source given was an IBM service manual. Does anyone know the quote I
refer to ?

Perhaps you're thinking of the essay "Benchmarks" I wrote for Embedded
Systems Programming, June 1998. It says, in part:

---
A guy walking home late one night sees a drunk on his hands
and knees beneath a street light.

``Dropped muh wallet,'' the drunk explains in a slur.
So the man obligingly joins him in his
search. After much futile crawling about, the man asks the drunk
where he was standing when the wallet fell.

``Way down there,'' he gestures in the direction of a darkened
alley.

Exasperated, ``Well then, why are you crawling around under
this street light?''

``The light's better here.''

And this, to me, is the problem of bad benchmarks in a nutshell.
Most people prefer to look near the existing street lights,
not where they're likely to find what they're looking for.
---

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[j0mbolar]

Perhaps you're thinking of the essay "Benchmarks" I wrote for Embedded
Systems Programming, June 1998. It says, in part:

---
A guy walking home late one night sees a drunk on his hands
and knees beneath a street light.

``Dropped muh wallet,'' the drunk explains in a slur.
So the man obligingly joins him in his
search. After much futile crawling about, the man asks the drunk
where he was standing when the wallet fell.

``Way down there,'' he gestures in the direction of a darkened
alley.

Exasperated, ``Well then, why are you crawling around under
this street light?''

``The light's better here.''

And this, to me, is the problem of bad benchmarks in a nutshell.
Most people prefer to look near the existing street lights,
not where they're likely to find what they're looking for.
---

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

I've tried googling for this paper but I get nothing.
Do you know of a place where I can download it?

 

[Chris Stiles]

Perhaps you're thinking of the essay "Benchmarks" I wrote for Embedded
Systems Programming, June 1998. It says, in part:

Hrm, thinking on it I think I orginally saw the quote in one of the
"Programming on Purpose" books - with that in mind I'll have to see if I can
dig it up.

 

[P.J. Plauger]

"P.J. Plauger" <[email protected]> wrote in message

I've tried googling for this paper but I get nothing.
Do you know of a place where I can download it?

I've written several hundred essays for magazines over the past couple
of decades, but only a few are online. AFAIK, this is not one of them.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Dave Vandervies]

(Or guess what would happen if your boss decided that you will be paid
per line of code written in the future - which is very easy to measure.
How many lines would you write to fill an array of 10000 ints completely
with zeroes? )

--------
#include <stdio.h>
#include <stdlib.h>

int main(int argc,char **argv)
{
unsigned i,nelems;
char *name;
if(argc!=3)
{
puts("use: zero_array <array-name> <number-of-elements>");
return EXIT_FAILURE;
}
name=argv[1];
if((nelems=strtol(argv[2],0,0))==0)
{
puts("use: zero_array <array-name> <number-of-elements>");
return EXIT_FAILURE;
}

for(i=0;i<nelems;i++)
printf("%s\n[\n%u\n]\n=\n0\n;\n",name,i);

return 0;
}
--------

I count 24, including blank ones. Of course, the number of lines used to
zero-fill an array in code written using this tool would be... excessive.


dave
:r! zero_array arr 10000