The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] core
Date: Mon, 18 Jun 2018 14:51:02 -0400	[thread overview]
Message-ID: <CAC20D2MR9OHLabn-P7v=vd3VJ_3j1CgOgjMaghTD_4zaPWAcjA@mail.gmail.com> (raw)
In-Reply-To: <20180618175638.383D418C086@mercury.lcs.mit.edu>

[-- Attachment #1: Type: text/plain, Size: 5390 bytes --]

On Mon, Jun 18, 2018 at 1:56 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>
>     > Just like I retold the Amdahl/Brooks story of the 8-bit byte and
> Amdahl
>     > thinking Brooks was nuts
>
> Don't think I've heard that one?

​Apologies for the repeat, if I have set this to TUHS before (I know I have
mentioned it in other places).​  Somebody else on this list mentioned David
Brailsford YouTube Video.  Which has more details, biut he had some of not
quite right.  I had watched it an we were communicating.   The actual story
behind the byte is a bit deeper than he describes in the lecture, which he
thanked me - as I have since introduced him to  my  old friend & colleague
Russ Robelen who was was the chief designer of the Model 50 and later lead
the ASC system with John Coche working for him.  Brailsford is right about
results of byte addressing and I did think his lecture is excellent and you
can learn a great deal.   That said, Russ tells the details of story like
this:

Gene Amdahl wanted the byte to be 6 bits and felt that 8 bits was
'wasteful' of his hardware.   Amdahl also did not see why more than 24 bits
for a word was really needed and most computations used words of course.
4, 6-bit bytes in a word seemed satisfactory to Gene.   Fred Brooks kept
kicking Amdahl out of his office and told him flatly - that until he came
back with things that were power's of 2, don't bother - we couldn't program
it.   The 32-bit word was a compromise, but note the original address was
only 24-bits (3, 8-bit bytes), although Brooks made sure all address
functions stored all 32-bits - which as Gordon Bell pointed out later was
the #1 thing that saved System 360 and made it last.


​BTW: ​
Russ and
​ ​
Ed Sussenguth invented speculative execution for the ACS system
​ a couple of years later​
.   I was
​ ​
harassing him
​ last January,​
because for 40 years we have been using his cool idea and it
​ ​
came back to bite us at Intel.  Here is the message cut/pasted from his
​ ​
email for context:

"I see you are still leading a team at Intel
​ ​
developing super computers and associated technologies. It certainly
​ ​
is exciting times in high speed computing.
​ ​
It brings back memories of my last work at IBM 50 years ago on the ACS
​ ​
project. You know you are old when you publish in the IEEE Annals of
​ ​
the History of Computing. One of the co-authors, Ed Sussenguth, passed
​ ​
away before our paper was published
​ ​
in
​ ​
2016.
​ ​
 https://www.computer.og/csdl/mags/an/2016/01/man2016010060.html
<https://www.computer.org/csdl/mags/an/2016/01/man2016010060.html>
​​
 Some
​ ​
of the work we did way back then has made the news in an unusual way
with the recent revelations on Spectre and Meltdown. I read the
​ ​
‘Spectre Attacks: Exploiting Speculative Execution’ paper yesterday
​ ​
trying to understand how speculative execution was being exploited.
​ ​
At
​ ​
ACS we were the first group at IBM to come up with the notion of the
​ ​
Branch Table and other techniques for speeding up execution.

I wish you were closer. I’d do love to hear your views on the state of
​ ​
computing today. I have a framed micrograph of the IBM Power 8 chip on
the wall in my office. In many ways the Power Series is an outgrowth
​ ​
of ACS.
​ ​
I still try to keep up with what is happening in my old field. The
​ ​
recent advances by Google in Deep Learning are breathtaking to me.
​  ​
Advances like AlphaGo Zero I never expected to see in my lifetime.
​"​



>
> But you can lose with that strategy too.
>
> Multics had a lot of sub-systems re-written from the ground up over time,
> and
> the new ones were always better (faster, more efficient) - a common even
> when
> you have the experience/knowledge of the first pass.
>
> Unfortunately, by that time it had the reputation as 'horribly slow and
> inefficient', and in a lot of ways, never kicked that:
>
>   http://www.multicians.org/myths.html
>
> Sigh, sometimes you can't win!

​Yep - although I think that may have been a case of economics.    Multics
for all its great ideas, was just a huge system, when Moores law started to
make smaller systems possible.  So I think your comment about thinking
about what you need now and what you will need in the future was part of
the issue.   ​


I look at Multics vs Unix the same way I look at TNC vs Beowulf clusters.
 At the time, we did TNC, we worked really hard to nail the transparency
thing and we did.   It was (is) awesome.  But it cost.   Tru64 (VMS and
other SSI) style clusters are not around today.  The hack that is Beowulf
is what lived on.   The key is that it was good enough and for most people,
that extra work we did to get rid of those seams just was not worth it.
And in the because Beowulf was economically successful, things were
implemented for it, that were never even considered for Tru64 and the SSI
style systems.     To me, Multics and Unix have the same history.
​   Multics was (is) cool; but Unix is similar; but different and too the
lead.   The key is that it was not a straight path.  Once Unix took over,
history went in a different direction.

Clem

[-- Attachment #2: Type: text/html, Size: 17304 bytes --]

  reply	other threads:[~2018-06-18 18:52 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 17:56 Noel Chiappa
2018-06-18 18:51 ` Clem Cole [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-06-21 22:44 Nelson H. F. Beebe
2018-06-21 23:07 ` Grant Taylor via TUHS
2018-06-21 23:38   ` Toby Thain
2018-06-21 17:40 Noel Chiappa
2018-06-21 17:07 Nelson H. F. Beebe
2018-06-21 13:46 Doug McIlroy
2018-06-21 16:13 ` Tim Bradshaw
2018-06-20 20:11 Doug McIlroy
2018-06-20 23:53 ` Tim Bradshaw
2018-06-19 12:23 Noel Chiappa
2018-06-19 12:58 ` Clem Cole
2018-06-19 13:53   ` John P. Linderman
2018-06-21 14:09 ` Paul Winalski
2018-06-19 11:50 Doug McIlroy
     [not found] <20180618121738.98BD118C087@mercury.lcs.mit.edu>
2018-06-18 21:13 ` Johnny Billquist
2018-06-18 14:51 Noel Chiappa
2018-06-18 14:58 ` Warner Losh
     [not found] <mailman.1.1529287201.13697.tuhs@minnie.tuhs.org>
2018-06-18  5:58 ` Johnny Billquist
2018-06-18 12:39   ` Ronald Natalie
2018-06-17 21:18 Noel Chiappa
2018-06-17 17:58 Noel Chiappa
2018-06-18  9:16 ` Tim Bradshaw
2018-06-18 15:33   ` Tim Bradshaw
2018-06-17 14:36 Noel Chiappa
2018-06-17 15:58 ` Derek Fawcus
2018-06-16 22:57 Noel Chiappa
     [not found] <mailman.1.1529175600.3826.tuhs@minnie.tuhs.org>
2018-06-16 22:14 ` Johnny Billquist
2018-06-16 22:38   ` Arthur Krewat
2018-06-17  0:15   ` Clem cole
2018-06-17  1:50     ` Johnny Billquist
2018-06-17 10:33       ` Ronald Natalie
2018-06-20 16:55       ` Paul Winalski
2018-06-20 21:35         ` Johnny Billquist
2018-06-20 22:24           ` Paul Winalski
2018-06-16 13:49 Noel Chiappa
2018-06-16 14:10 ` Clem Cole
2018-06-16 14:34   ` Lawrence Stewart
2018-06-16 15:28     ` Larry McVoy
2018-06-16 14:10 ` Steve Nickolas
2018-06-16 14:13   ` William Pechter
2018-06-16 13:37 Noel Chiappa
2018-06-16 18:59 ` Clem Cole
2018-06-17 12:15 ` Derek Fawcus
2018-06-17 17:33 ` Theodore Y. Ts'o
2018-06-17 19:50   ` Jon Forrest
2018-06-18 14:56   ` Clem Cole
2018-06-18 12:36 ` Tony Finch
2018-06-16 12:58 Doug McIlroy
2018-06-20 11:10 ` Dave Horsfall
2018-06-16 12:51 Noel Chiappa
2018-06-16 13:11 ` Clem cole
2018-06-15 15:25 Noel Chiappa
2018-06-15 23:05 ` Dave Horsfall
2018-06-15 23:22   ` Lyndon Nerenberg
2018-06-16  6:36     ` Dave Horsfall
2018-06-16 19:07       ` Clem Cole
2018-06-18  9:25         ` Tim Bradshaw
2018-06-19 20:45           ` Peter Jeremy
2018-06-19 22:55             ` David Arnold
2018-06-20  5:04               ` Peter Jeremy
2018-06-20  5:41                 ` Warner Losh
2018-06-15 11:19 A. P. Garcia
2018-06-15 13:50 ` Steffen Nurpmeso
2018-06-15 14:21 ` Clem Cole
2018-06-15 15:11   ` John P. Linderman
2018-06-15 15:21     ` Larry McVoy
2018-06-16  1:08   ` Greg 'groggy' Lehey
2018-06-16  2:00     ` Nemo Nusquam
2018-06-16  2:17     ` John P. Linderman
2018-06-16  3:06     ` Clem cole
2018-06-20 10:06 ` Dave Horsfall

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='CAC20D2MR9OHLabn-P7v=vd3VJ_3j1CgOgjMaghTD_4zaPWAcjA@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@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).