The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Larry McVoy <lm@mcvoy.com>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] PDP-11 legacy, C, and modern architectTures
Date: Tue, 26 Jun 2018 22:18:43 -0400	[thread overview]
Message-ID: <20180627021843.GA31920@thunk.org> (raw)
In-Reply-To: <20180626215905.GH8150@mcvoy.com>

One of the things which is probably causing a lot of hang ups is the
phrase "low-level language".  What is exactly meant by that?  The
article actually uses multiple definitions of "low-level language",
and switches between them when it is convenient, or as a rhetorical
trick.

There is at least one of his points that I very much agree with, which
is the abstract model which is exported by the C programming paradigm
is very different from what totality of what the CPU can do.  Consider
the oft-made admonition that most humans can't program in assembler
more efficiently than the compiler.  Think about that for a moment.
That saying is essentially telling us that the compiler is capable of
doing a lot of things behinds our back (which goes against the common
understanding of what low-level language does), and second, that
modern CPU's has gotten too complicated for most humans to be able to
program directly, either comfortably or practically.

Also, all of these compiler optimizations are not _mandatory_.  They
are there because people really want performance.  You are free to
disable them if you care about predictability and avoiding the "any
sufficiently advanced compiler is indistinguishable from a malicious
adversary" dynamic.  In fact, if are writing a program where you are,
more often than not, I/O bound and/or fundamentally bound by memory
bandwidth, turning off a lot of these compiler optimizations might be
the right thing to do, as they may not buy you much, and given you
much in the way of headaches.  There is a reason why the Linux kernel
compiles with the GCC flags:

	-fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks \
	-fstack-protector-strong -fno-var-tracking-assignments \
	-femit-struct-debug-baseonly -fno-var-tracking \
	-fno-inline-functions-called-once -fno-strict-overflow \
	-fno-merge-all-constants -fmerge-constants -fno-stack-check

By the way, I disagree with Chisnall's assertion that low-level
languages are fast.  If you believe that compilers can often do a
better job than humansh writing assembly, does that mean that since
assembly code isn't fast that it's not a low-level language?)  And the
performance wars is an important part of dynamic --- at the end of the
day, the vast majority of people choose performance as the most
important driver of their purchasing decision.  They may pay lip
service to other things, including security, robustness, etc., but if
you take a look at what they actually _do_, far more often than not,
they choose fast over slow.

I see this an awful lot in file system design.  People *talk* a great
game about how they care about atomicity, and durability, etc., but
when you look at their actual behavior as opposed to expressed
desires, more often than not what they choose is again, fast over 
slow.  And so I have an extension to the fictional dialog to Pillai's
presentation for his 2014 OSDI paper:

Experienced Academic: Real file systems don't do that.

   But <...> does just that.

Academic: My students would flunk class if they built a file system that way.

Cynical Industry Developer's rejoinder: A file system designed the way
   you propose would likely be a commercial failure, and if it was the
   only/default FS for an OS, would probably drag the OS down to
   failure with it.


And this goes to Spectre, Meltdown, TLBleed, and so on.  Intel built
processors this way because the market _demanded_ it.  It's for the
same reason that Ford Motor Company built gas-guzzling pickup trucks.
Whether or not Maimi Beach will end up drowning under rising sea
levels never entered into the the consumer or the manufacturer's
consideration, at least not in any real way.

It's very easy to criticize Intel for engineering their CPU's the way
they did, but if you want to know who to blame for massively high
ILP's and caching, and compilers that do all sorts of re-ordering and
loop rewriting behind the developer's back, just look in the mirror.
It's the same as why we have climate change and sea level rise.

"We have met the enemy and he is us". -- Pogo (Walt Kelly)

						- Ted

  parent reply	other threads:[~2018-06-27  2:45 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-26 17:54 [TUHS] PDP-11 legacy, C, and modern architectures Nelson H. F. Beebe
2018-06-26 18:03 ` Cornelius Keck
2018-06-26 21:21   ` Nelson H. F. Beebe
2018-06-26 21:56   ` Kurt H Maier
2018-06-26 18:52 ` Ronald Natalie
2018-06-26 19:01 ` Ronald Natalie
2018-06-26 21:16   ` Arthur Krewat
2018-06-26 21:50     ` Larry McVoy
2018-06-26 21:54       ` Ronald Natalie
2018-06-26 21:59         ` Larry McVoy
2018-06-26 22:20           ` Bakul Shah
2018-06-26 22:33             ` Arthur Krewat
2018-06-26 23:53               ` Bakul Shah
2018-06-27  8:30             ` Tim Bradshaw
2018-06-26 22:33           ` Andy Kosela
2018-06-27  0:11             ` Bakul Shah
2018-06-27  6:10               ` arnold
2018-06-27  2:18           ` Theodore Y. Ts'o [this message]
2018-06-27  2:22             ` [TUHS] PDP-11 legacy, C, and modern architectTures Theodore Y. Ts'o
2018-06-28 14:36             ` Steffen Nurpmeso
2018-06-27 11:26         ` [TUHS] PDP-11 legacy, C, and modern architectures Tony Finch
2018-06-27 14:33           ` Clem Cole
2018-06-27 14:38             ` Clem Cole
2018-06-27 15:30             ` Paul Winalski
2018-06-27 16:55               ` Tim Bradshaw
2018-06-27  6:27     ` arnold
2018-06-27 16:00 ` Steve Johnson
2018-06-28  4:12   ` Bakul Shah
2018-06-28 14:15     ` Theodore Y. Ts'o
2018-06-28 14:40       ` Larry McVoy
2018-06-28 14:55         ` Perry E. Metzger
2018-06-28 14:58           ` Larry McVoy
2018-06-28 15:39             ` Tim Bradshaw
2018-06-28 16:02               ` Larry McVoy
2018-06-28 16:41                 ` Tim Bradshaw
2018-06-28 16:59                   ` Paul Winalski
2018-06-28 17:09                   ` Larry McVoy
2018-06-29 15:32                     ` tfb
2018-06-29 16:09                       ` Perry E. Metzger
2018-06-29 17:51                       ` Larry McVoy
2018-06-29 18:27                         ` Tim Bradshaw
2018-06-29 19:02                         ` Perry E. Metzger
2018-06-28 20:37                 ` Perry E. Metzger
2018-06-28 15:37         ` Clem Cole
2018-06-28 20:37           ` Lawrence Stewart
2018-06-28 14:43       ` Perry E. Metzger
2018-06-28 14:56         ` Larry McVoy
2018-06-28 15:07           ` Warner Losh
2018-06-28 19:42           ` Perry E. Metzger
2018-06-28 19:55             ` Paul Winalski
2018-06-28 20:42             ` Warner Losh
2018-06-28 21:03               ` Perry E. Metzger
2018-06-28 22:29                 ` Theodore Y. Ts'o
2018-06-29  0:18                   ` Larry McVoy
2018-06-29 15:41                     ` Perry E. Metzger
2018-06-29 18:01                       ` Larry McVoy
2018-06-29 19:07                         ` Perry E. Metzger
2018-06-29  5:58                   ` Michael Kjörling
2018-06-28 20:52             ` Lawrence Stewart
2018-06-28 21:07               ` Perry E. Metzger
2018-06-28 16:45       ` Paul Winalski
2018-06-28 20:47         ` Perry E. Metzger
2018-06-29 15:43         ` emanuel stiebler
2018-06-29  2:02       ` Bakul Shah
2018-06-29 12:58         ` Theodore Y. Ts'o
2018-06-29 18:41           ` Perry E. Metzger

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=20180627021843.GA31920@thunk.org \
    --to=tytso@mit.edu \
    --cc=lm@mcvoy.com \
    --cc=tuhs@minnie.tuhs.org \
    /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).