The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: doug@cs.dartmouth.edu (Doug McIlroy)
Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!)
Date: Mon, 05 Feb 2018 10:20:11 -0500	[thread overview]
Message-ID: <201802051520.w15FKBat001896@coolidge.cs.Dartmouth.EDU> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

> My experience is that the problems involved in making a program faster are 
> often quite interesting and fun to work on.  But the problems making things
> fit in a small space are, IMHO, really deadly.

First make things "as simple as possible, but no simpler" (Einstein). Ken and
Dennis not only cut out fat, they also found generalizations that combined
traditionally disparate features, so the new whole was smaller (and more 
comprehensible) than the sum of the old parts. The going gets tough in the 
presence of constraints on space or time. Steve's perception, I think, is 
colored by the experience of facing hard limits on space, but not on time.

Describing one complication of hard time constraints, John Kelly used to
say that the Packard Bell 250 was "the only machine I ever used where
you transfer to a time of day rather than a memory location". (The delay-
line memory had two instruction formats: one was operation + address-of-
next-instruction, the other was just the operation--the next instruction
being whatever came out of the delay line when the operation ended. The 
latter mode minimized both execution time and code space, but the attention
one had to pay to time was, to borrow Steve's phrase, "really deadly".)

Design tradeoffs for efficiency pose an almost moral conundrum:
whether to make things fast or make them easy. For example, the
classic Unix kernel typically did table lookup by linear search,
whereas Linux (when I last looked) typically used binary search. 
The price of Linux's choice is that one must take care to keep 
the tables sorted. Heavy discipline has to be imposed on making
entries and deletions.

Doug


             reply	other threads:[~2018-02-05 15:20 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05 15:20 Doug McIlroy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-02-04  0:37 Dan Cross
2018-02-04  2:59 ` Nemo Nusquam
2018-02-04  5:06   ` Wesley Parish
2018-02-04  5:18     ` Warner Losh
2018-02-05 19:43     ` Paul Winalski
2018-02-05 21:19       ` Michael Kjörling
2018-02-06  0:37         ` Steve Nickolas
2018-02-06  0:45           ` Warner Losh
2018-02-06  9:14           ` Wesley Parish
2018-02-04  9:14   ` Angelo Papenhoff
2018-02-04 14:15     ` arnold
2018-02-04 17:21     ` Ron Natalie
2018-02-04 20:05       ` Dan Cross
2018-02-04 20:55         ` Nemo
2018-02-04 20:57           ` Warner Losh
2018-02-04 20:59           ` Jon Steinhart
2018-02-04 22:12             ` Clem Cole
2018-02-05  1:32             ` William Cheswick
2018-02-05  1:44               ` Dave Horsfall
2018-02-04 21:04         ` Toby Thain
2018-02-04 22:22           ` Andy Kosela
2018-02-04 22:43         ` Dave Horsfall
2018-02-04 22:54           ` George Michaelson
2018-02-05  3:35           ` Ron Natalie
2018-02-05  3:40           ` Dan Cross
2018-02-05 13:48             ` William Cheswick
2018-02-05 14:31               ` Ron Natalie
2018-02-05 21:51               ` Dave Horsfall
2018-02-05 21:57                 ` Ron Natalie
2018-02-05 22:31                   ` Grant Taylor
2018-02-05 23:16                     ` Arthur Krewat
2018-02-05 23:49                       ` Grant Taylor
2018-02-06 17:42                       ` Ron Natalie
2018-02-06 18:23                         ` Arthur Krewat
2018-02-05 23:10                   ` Charles Anthony
2018-02-05 23:20                   ` Arthur Krewat
2018-02-05 23:28                     ` Dave Horsfall
2018-02-05 23:36                       ` Arthur Krewat
2018-02-05 23:52                         ` George Michaelson
2018-02-06 14:52                 ` Steffen Nurpmeso
2018-02-05 23:18               ` Lyndon Nerenberg
2018-02-06 21:51               ` Dan Cross
2018-02-06 23:14                 ` Nemo Nusquam
2018-02-06 23:22                   ` Warner Losh
2018-02-07  3:03                     ` Dave Horsfall
2018-02-07  1:23                 ` Dave Horsfall
2018-02-07  1:33                   ` Clem Cole
2018-02-07  1:54                   ` Dan Cross
2018-02-07 18:01                     ` Tony Finch
2018-02-09  2:35                       ` Wesley Parish
2018-02-07 18:50                     ` Bakul Shah
2018-02-15 13:23                     ` Tim Bradshaw
2018-02-05  0:27         ` Kurt H Maier
2018-02-05  0:41     ` Robert Brockway
2018-02-04  9:11 ` Donald ODona
2018-02-04 23:25 ` Dave Horsfall
2018-02-04 23:46   ` Bakul Shah
2018-02-04 23:58     ` Dave Horsfall
2018-02-05  0:06 ` Robert Brockway
2018-02-05  5:37   ` Steve Johnson
2018-02-05  5:53     ` Greg 'groggy' Lehey
2018-02-05 10:49       ` Ron Natalie
2018-02-05  6:57     ` Robert Brockway

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=201802051520.w15FKBat001896@coolidge.cs.Dartmouth.EDU \
    --to=doug@cs.dartmouth.edu \
    /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).