Re: Letter to US Sen. Byron Dorgan re unpaid overtime

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/01/04 

Date: 1 Jan 2004 11:05:15 -0800

Richard Heathfield <invalid@address.co.uk.invalid> wrote in message news:<3ff415a7@news2.power.net.uk>...
> Edward G. Nilges wrote:
>
> > Richard Heathfield <invalid@address.co.uk.invalid> wrote in message
> > news:<3ff2d599@news2.power.net.uk>...
> >>
> >> This is a rather non-intuitive result, but I now think I understand why
> >> it happens. It seems that gcc is inlining the strlen, and putting it
> >> inside the loop necessitates some dancing around the bytes to keep
> >> everything smooth, whereas saving the strlen result gives much cleaner
> >> code.
> >
> > That's an interesting result, but as usual you fail to see the forest
> > for the trees. I wasn't addressing whether the specific code was more
> > storage efficient.
> >
> > I was instead pointing out that in general there can be a savings in
> > STORAGE if you "waste time" by "unnecessarily" re-evaluating values.
>
> You have said that there is no significant loss of time using strlen in a
> loop rather than once in advance of the loop. I have shown that to be
> wrong. You have said, in message
>
> <f5dda427.0312291645.3cdbbae7@posting.google.com>,
>
> that using a temporary variable neglects storage efficiency, and I have
> shown that to be wrong, too.

You have run a specific program using a specific compiler. Your
results prove nothing except that the GNU C compiler does inlining (if
its options are set).

One temporary value doesn't, of course, neglect storage efficiency
(any more than using strlen neglects time efficiency when the input
string length is bounded by the size of a console input). But in
general there is a trade off between recalculation to save storage at
the expense of time, and use of temporary values to save time at the
expense of storage. In fact, and as Brian Kernighan showed long ago in
The Elements of Programming Style, the tradeoff is three-way when you
factor in clarity.

Put simply: this is a forest and this is a tree.

>
>
> > I am, dear Richard, a high-level kind of guy while you remain, well,
> > let's be charitable, a detail man.
>
> It is through charity that I assume you to be incompetent. If I were not so
> charitable, I might think you were trying deliberately to mislead the
> newbies who read this group with your ludicrously false claims.
>
> > People in this ng have said "Nilges is not a programmer." Well,
> > although the Google whois tool says "Edward Nilges is a programmer",
>
> If you write programs, you're a programmer. If you write bad programs, that
> doesn't mean you're not a programmer. It just means you're a bad
> programmer.
>
> > I
> > have long been somewhat ashamed of the job title, because I have long
> > encountered this type of bonehead logic, in which a single automated
> > case is thought to refute human wisdom and knowledge.
>
> A single counter-example is enough to refute a "proof". You pay far too
> little attention to counter-examples.
>
Oh, gee, the high school graduate AGAIN lectures me on logic. How very
droll.

A single counter-example only refutes a deductive proof. It doesn't
refute an inductive generalization.

My dear chap, are there no extension courses for adults at the local
workingman's college? I do suggest a class in logic.

Now, I am well aware at the workingman's rage against the toffs who
generalize in such a way that they deny the reality of materials in
traditional engineering, and of software behavior, for the very good
reason that I work for a living.

But this rage issues in a rage against "generalization" per se, in
which the workingman fantasizes that he does not generalize and that
one case "refutes" a generalization never meant to be deductive and
universal.

The problem is that one cannot get by without "generalization" in the
form of forming a theory which is then tested against practice and
that when you do not recognize this, your unspoken and unexamined bias
becomes the rule. Cf. Kant in this regard.

 
> > If today a
> > "programmer" is the type of person who makes this mistake, well, OK, I
> > am not a programmer.
>
> Programmers need not be perfect to be programmers, but seeking after
> perfection is a useful trait.
>
You don't seek after perfection. I have pointed out to you the
deficiencies of C but you are content to remain with C. Instead you
seek always to be viewed as right.
 
> > The classic case of the tradeoff between space and time is an
> > interpreter, which continually re-evaluates source to machine language
> > and is "slow", but saves space when storage is tight.
>
> As a matter of fact, a traditional interpreter does not re-evaluate source
> to machine language, and is not a particularly fine example of
> space-saving.
>
If what you mean is that many interpreters translate source code to a
compressed or bytecode representation for some efficiency I quite
agree. If what you mean is that other interpreters gain a further
efficiency increment by threading and just in time compilation I again
agree.

However, the IBM 1401 Fortran compiler (and similar products of its
era designed by IBM for mid and small range users of the IBM 1401, the
IBM 360 models 20 and 30, the IBM 1130 and similar systems) would not
have been feasible had it generated code in the manner of compilers
for big iron. Again, it bought do-ability by trading efficiency for
storage.
 
> > I first
> > encountered this trade-off in the IBM 1401 Fortran compiler in 1971
>
> I don't believe you...
>
Believe whatever you like. I don't care. You are a tout and a fraud
and your low opinion makes me look good.
 
> > (cf. my article in IEEE Transactions on the History of Software for
> > Spring/Summer 1999.)
>
> ...so could you please provide a URL for this reference?
>
Do your own homework.
 
> <OT stuff snipped>
>
> >
> > You think you've refuted my argument based on one case,
>
> I have provided evidence that you're wrong. It is certainly possible for
> evidence to exist that supports your view, but a single counter-example is
> sufficient to render your (unmodified) position untenable. That won't stop
> /you/ from holding that position, obviously. You seem to delight in holding
> untenable positions.
>
Again, I refer you to Milton Keynes or the local Workingman's
Institute for a class in Logic.
 
> > and I am
> > certain you are capering and gibbering in the chip shop or Internet
> > cafe as we speak.
>
> You are certain to be wrong (because I am not), and we are not speaking.
>
> >
> > But I really think that given your detail orientation, and my broader
> > view, that I should be your manager.
>
> Were that ever to come to pass, I would offer my resignation immediately.
>
It would be accepted.
 
> > First thing I'd do would be to
> > have you drop all use of the outdated C language,
>
> I don't /use/ the outdated C language (by which I presume you mean K&R C). I
> use ISO standard C.
>
That's even worse. Hey, let's standardise our bugs!
 
> > on pain of
> > termination.
>
> Is /that/ a death threat?
>
No. I said that if I had the misfortune to be your manager, I would
force you to cease using C immediately on pain of immediate
termination from your job. Perhaps in the UK, with its extended
"dole", this would not frighten you.
 
> > [...] and your folly shows the
> > broader folly of benchmarks. To repeat: in general and in the large,
> > one trades off speed efficiency for storage economy by re-evaluating.
>
> Show me one sensible example of well-written C that backs up your point.
> Just one.
>
No, I am too busy.
 
> > I retract when I am wrong.
>
> Not always. Hardly ever, in fact. For you are usually wrong, and you rarely
> retract.

Relevant Pages

  • Re: sizeof([ALLOCATED MEMORY])
    ... No one is discussing mandated efficiency. ... The proposal is an expanded interface giving the programmer more ... the C language definition, I think you do the creators of this ...
    (comp.lang.c)
  • Re: Can someone spot the error here?
    ... the compiler can and should assume ... but the programmer is at option to ... a language like Pascal is founded on. ... Wirth was looking both to compiler efficiency, ...
    (comp.lang.pascal.misc)
  • Re: Efficiency (was Questions (Space))
    ... Java programmer what the point of a function that did nothing but assign one ... He's right, "efficiency" is a meaningless word by itself, unless you've ... the cost of developing new programs is the ... If the operating system and have been built using ...
    (rec.arts.sf.composition)
  • Re: C++ in embedded systems
    ... >It depends on which object support you are refering to. ... >If a programmer was asked to produce an implementation, ... >>compiler or the relative efficiency of language forms (they may pay it ... >our favorite compiler, is feeling the heat. ...
    (comp.os.linux.embedded)