From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-reply-to: Your message of "Mon, 29 Oct 2012 19:36:16 EDT."
	<74f73b64cc6de4a3bd10367591439816@kw.quanstro.net>
References: <15723310.yIARpoJMSL@coil>
	<4824335454f1b1d47dbc8439b4af8ea3@kw.quanstro.net>
	<20121029223541.8C198B827@mail.bitblocks.com>
	<0f05642b113b3ecfc160e82a9ca4db32@brasstown.quanstro.net>
	<20121029232652.5160BB827@mail.bitblocks.com>
	<74f73b64cc6de4a3bd10367591439816@kw.quanstro.net>
Date: Mon, 29 Oct 2012 17:35:01 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20121030003501.AE691B827@mail.bitblocks.com>
Subject: Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
Topicbox-Message-UUID: ccb8fb62-ead7-11e9-9d60-3106f5b1d025

On Mon, 29 Oct 2012 19:36:16 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > No disagreement there on "requiring" optimization. But my
> > point was that a programmer should understand the standard
> > rather than complain when he gets "surprised" due to his lack
> > of knowledge.
>
> i agree that one should know the language.  but i'm not sure i'll
> say it's the programmer's fault when the compiler does things to
> the programmer.  that to me goes a bit too far.

Not a question of fault but IMHO a programmer, like a
carpenter or anyone who does real work, has to experiment and
learn the strengths and weaknesses of his tools of his trade
if he wants to become competent.

The language standard can only mandate what you can do within
the language.  For instace, if the blog writer had done this:

    ...
    memcpy(a, 0, sizeof a);
    for (i = 0; i < sizeof a; i++)
	assert(a[i] == 0);
    return 0;
}

He would have seen that every a[i] was indeed 0. But if you
use means external to the language (such as used a debugger or
look at the assembly language) to check side-effects, you get
to see the underside of optimization. Ugly, confusing and
possibly surprising. If you want to do something not covered
in the standard, learn what the compiler does and find a
compiler dependent way.

> > /sys/src/cmd follows plan9 c, not c99, right? But pick a
> > similar set of programs.  If this happens, I claim it would be
> > because programs assume something not guaranteed by the
> > compiler.
>
> and i can design a standards-compatable compiler that will break
> most any c program.

Care to give an example? I am genuinely interested. The C
standard is far from perfect but it has worked well enough.
[Where is doug gywn when we need him?]

> what i think has broken down is common sense among compiler
> writers.  they're too focused on being fast, and not focused enough
> on being *useful*.

I agree but I am afraid they do that because that is what the
market demands.  Pretty much most of the software that the
Internet runs on + used by most people + businesses uses C or
C++ so C/C++ and their standards have been *useful* (but see
below). Fast does matter when you scale up (a big company may
need 18K servers instead of 20K and that results in savings
and less heat generation).

If you want to whine, whine about the fact that *we* (all of
us) have lost common sense in pretty much every field.  Food,
medicine, media, politics, religion, consumption, you name it.

> > > > > it goes without saying, i think a compiler that largely does what you
> > > > > ask it to optimizes the scarce resource: developer time.
> > > >
> > > > That is a separate issue.
> > >
> > > actually, i think it *is* the issue.
> >
> > Best way to save developer time is to program in a HLL and not
> > worry about bit fiddling. C is not a HLL.
>
> this is a spurious argument, since we are in fact talking about c.

Sorry but IMHO "saving developer time" & C don't mix well. I
am just pointing out what modern C is and how to survive, not
what it should be.  I gave up on that a long time ago!