9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Bakul Shah <bakul@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
Date: Mon, 29 Oct 2012 17:35:01 -0700	[thread overview]
Message-ID: <20121030003501.AE691B827@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Mon, 29 Oct 2012 19:36:16 EDT." <74f73b64cc6de4a3bd10367591439816@kw.quanstro.net>

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!



  parent reply	other threads:[~2012-10-30  0:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29  9:45 dexen deVries
2012-10-29 10:12 ` tlaronde
2012-10-29 13:43   ` erik quanstrom
2012-10-29 13:35 ` erik quanstrom
2012-10-29 22:35   ` Bakul Shah
2012-10-29 22:47     ` Charles Forsyth
2012-10-29 23:05       ` Bakul Shah
2012-10-29 23:07         ` erik quanstrom
2012-10-29 23:15           ` David Leimbach
2012-10-29 23:20             ` erik quanstrom
2012-10-29 23:53               ` andrey mirtchovski
2012-10-29 23:59                 ` Kurt H Maier
2012-10-29 23:10     ` erik quanstrom
2012-10-29 23:26       ` Bakul Shah
2012-10-29 23:31         ` Bakul Shah
2012-10-29 23:36         ` erik quanstrom
2012-10-29 23:58           ` Charles Forsyth
2012-10-30  0:52             ` Bakul Shah
2012-10-30  1:01               ` erik quanstrom
2012-10-30  7:55             ` tlaronde
2012-10-30  0:35           ` Bakul Shah [this message]
2012-10-30  1:10             ` erik quanstrom
2012-10-30  3:06               ` Bakul Shah
2012-10-30  3:16                 ` Corey Thomasson
2012-10-30 13:08                   ` erik quanstrom
2012-10-30 15:15                     ` arnold
2012-10-30  1:46             ` cinap_lenrek
2012-10-30  1:21         ` Kurt H Maier
2012-10-30  8:07         ` tlaronde
2012-10-30 10:26         ` Richard Miller
2012-10-30 10:39           ` dexen deVries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121030003501.AE691B827@mail.bitblocks.com \
    --to=bakul@bitblocks.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).