The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (scj@yaccman.com)
Subject: [TUHS] Early Unix function calls: expensive?
Date: Sun, 3 Jan 2016 18:24:55 -0800	[thread overview]
Message-ID: <07cc4a0aa17d242be5e26bbcd66c1c55.squirrel@webmail.yaccman.com> (raw)
In-Reply-To: <20160104013151.C296718C0A0@mercury.lcs.mit.edu>

> A routine had to be pretty lengthy before it was worth paying the
> overhead, in
> order to amortize the calling cost across a fair amount of work (although
> of
> course, getting access to another three register variables could make the
> compiled output for the routine somewhat shorter).
>
>         Noel
>

I remember Dennis Ritchie telling me that the C compiler itself got
smaller and faster when he added register variables (and used them...)

I used to tell people that the time required to make a good optimizing C
compiler grew as the cube of the size of the instruction manual, including
the appendix on instruction execution timing.   These days they don't even
bother to have such an appendix, because timing depends on so many arcane
internal pipe stalls, memory refreshes, cache misses, etc. that it is
effectively uncomputible.  And then people wonder why
compiled code isn't very "good"...

At UC Berkeley, not long after they got their VAX, Prof. Susan Graham
gave a year-long class on optimization.  The first semester, the  students
learned all the relevant algorithms, etc.  The second semester,
they each implemented an optimization and integrated them into the Unix
F77 compiler.  As I recall, they got a 15% speedup on a set of benchmarks.

Then, over the summer, a student who had studied the VAX hardware
realized that the typical FORTRAN expression ( A = B op C ) was dealing
with three 32-bit addresses, and the resulting instruction was too big
to fit into the instruction lookahead buffer.  Allocating a register to
point to the internal (static) variables for each routine and using a
16-bit offset made these instructions fit, and the performance
improvement (for what was a 2-day fix) was 20%.

The moral of the story is that overhead kills you, and unknown or
uncharacterized overhead is especially fatal...






  reply	other threads:[~2016-01-04  2:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04  1:31 Noel Chiappa
2016-01-04  2:24 ` scj [this message]
2016-01-04  4:24   ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2016-01-04 12:53 Noel Chiappa
2016-01-04  2:21 Clem Cole
2016-01-04  1:59 Norman Wilson
2016-01-04 15:09 ` John Cowan
     [not found] <mailman.3.1451865187.15972.tuhs@minnie.tuhs.org>
2016-01-04  1:08 ` Johnny Billquist
2016-01-04  1:29   ` Larry McVoy
2016-01-03 23:35 Warren Toomey
2016-01-03 23:53 ` Tim Bradshaw
2016-01-04  0:01   ` John Cowan
2016-01-04  4:40     ` Armando Stettner
2016-01-04  8:52       ` Tim Bradshaw
2016-01-04 17:29         ` Larry McVoy
2016-01-04 13:50       ` Clem Cole
2016-01-05  2:00       ` Ronald Natalie
2016-01-05 15:13         ` Clem Cole
2016-01-05 16:46           ` John Cowan
2016-01-05 17:33             ` Diomidis Spinellis
2016-01-05 17:42             ` Clem Cole
2016-01-05 17:28           ` Ronald Natalie
2016-01-05 17:43             ` Clem Cole
2016-01-05 17:46               ` Ronald Natalie
2016-01-05 18:03                 ` Warner Losh
2016-01-05 18:24                   ` Ronald Natalie
2016-01-05 20:26                     ` scj
2016-01-05 20:49                     ` John Cowan
2016-01-05 23:24         ` Dave Horsfall
2016-01-05 23:55           ` Ronald Natalie
2016-01-04  0:00 ` John Cowan
2016-01-04  0:42 ` scj
2016-01-04 11:35   ` Tony Finch

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=07cc4a0aa17d242be5e26bbcd66c1c55.squirrel@webmail.yaccman.com \
    --to=scj@yaccman.com \
    /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).