The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (Steve Johnson)
Subject: [TUHS] Questions for TUHS great minds
Date: Wed, 11 Jan 2017 10:34:29 -0800	[thread overview]
Message-ID: <99f1301695eb38762765b91bff57b0486bc71af6@webmail.yaccman.com> (raw)
In-Reply-To: <CAAFR5pZBZWFLLR03+xHZng-wfJHvNxqX7WP6p=tuM4rMxmhfaw@mail.gmail.com>

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



>>  Or does the idea of a single OS disintegrate into a fractal cloud
of zero-cost VM's?  What would a meta-OS need to manage that?  Would
we still recognize it as a Unix?

This may be off topic, but the aim of studying history is to avoid the
mistakes of the past.  And part of that is being honest about where
we are now...

IMHO, hardware has left software in the dust.  I figured out that if
cars had evolved since 1970 at the same rate as computer memory, we
could now buy 1,000 Tesla Model S's for a penny, and each would have a
top speed of 60,000 MPH.  This is roughly a factor of a trillion in
less than 50 years.

For quite a while, hardware (Moore's law) was giving software
cover--the hardware speed and capacity was exceeding the rate of bloat
in software.  For the last decade, that's stopped happening (the
hardware speed, not the software bloat!)   What hardware is now
giving us is many many more of the same thing rather than the same
thing faster.  To fully exploit the hardware, the old model of
telling a processor "do this, then do this, then do this" simply
doesn't scale.  Things like multicore look to me like a desperate
attempt to hold onto an outmoded model of computing in the face of a
radically different hardware landscape.

The company I'm working for now, Wave Computing, is building a chip
with 16,000 8-bit processors on a chip.  These processors know how to
snuggle up together and do 16-, 32-, and 64-bit arithmetic.  The chip
is intended to be part of systems with as many as a quarter million
processors, with machine learning being one possible target.  There
are no global signals on the chip (e.g., no central clock).  (The
hardware people aren't perfect--it's not yet sunk in that making a
billion transistors operate fast while remaining in synch is
ultimately an impossible goal as the line sizes get smaller).

Chips like ours are not intended to be general purpose -- they act
more like FPGA's. They allow tremendous resources to be focused on a
single problem at a time.  And the focus to change quickly as
desired.  They aren't good for everything.  But I do think they
represent the current state of hardware pretty well, and the trends
are strongly towards even more of the same.  

The closest analogy of programming for the chip is microcode -- it's
as if you have a programmable machine with hundreds or thousands of
"instructions" that are far more powerful than traditional
instructions, able to operate on structured data and do many
arithmetic operations.  And you can make new instructions at will. 
The programming challenge is to wire these instructions together to
get the desired effect. 

This may not be the only path to the future, and it may fail to
survive or be crowded out by other paths.  But the path we have been
on for the last 50 years is a dead end, and the quicker we wise up and
grab the future, the better...

Steve

PS: another way to visualize the hardware progress:  If we punched
out a petabyte of data onto punched cards, the card deck height would
be 6 times the distance to the moon!  Imagine the rubber band....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170111/64d9c337/attachment.html>


  parent reply	other threads:[~2017-01-11 18:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11  2:33 Robert Swierczek
2017-01-11 16:25 ` Ron Natalie
2017-01-11 16:50   ` Jacob Goense
2017-01-11 17:01     ` Corey Lindsly
2017-01-11 17:54       ` Marc Rochkind
2017-01-11 20:32       ` Jacob Goense
2017-01-11 18:34 ` Steve Johnson [this message]
2017-01-11 19:46   ` Steffen Nurpmeso
2017-01-17 13:09   ` Tim Bradshaw
2017-01-17 13:36     ` Michael Kjörling
2017-01-17 19:55     ` Steve Johnson
2017-02-01 23:32       ` Erik E. Fair
2017-01-17 14:27 Nelson H. F. Beebe

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=99f1301695eb38762765b91bff57b0486bc71af6@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).