The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Perry E. Metzger" <perry@piermont.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] PDP-11 legacy, C, and modern architectures
Date: Thu, 28 Jun 2018 10:43:29 -0400	[thread overview]
Message-ID: <20180628104329.754d2c19@jabberwock.cb.piermont.com> (raw)
In-Reply-To: <20180628141538.GB663@thunk.org>

On Thu, 28 Jun 2018 10:15:38 -0400 "Theodore Y. Ts'o" <tytso@mit.edu>
wrote:
> I'll note that Sun made a big bet (one of its last failed bets) on
> this architecture in the form of the Niagra architecture, with a
> large number of super "wimpy" cores.  It was the same basic idea
> --- we can't make big fast cores (since that would lead to high
> ILP's, complex register rewriting, and lead to cache-oriented
> security vulnerabilities like Spectre and Meltdown) --- so instead,
> let's make lots of tiny wimpy cores, and let programmers write
> highly threaded programs!  They essentially made a bet on the
> web-based microservice model which you are promoting.
>
> And the Market spoke.  And shortly thereafter, Java fell under the
> control of Oracle....  And Intel would proceed to further dominate
> the landscape.

I'll be contrary for a moment.

Huge numbers of wimpy cores is the model already dominating the
world. Clock rates aren't rising any longer, but (in spite of claims
to the contrary) Moore's law continues, very slightly with shrinkage
of feature size (which is about to end) and more dominantly with
increasing the number of transistors per square mil by going into
3D. Dynamic power usage also scales as the square of clock rate, so
larger numbers of lower clocked cores save a boatload of heat, and at
some point you have too many transistors in too small an area to take
heat out if you're generating too much.

Some data points:

1. All the largest compute platforms out there (Google, Amazon, etc.)
   are based on vast numbers of processors integrated into a giant
   distributed system. You might not see this as evidence for the
   trend, but it is. No one can make a single processor that's much
   faster than what you get for a few hundred bucks from Intel or AMD,
   so the only way to get more compute is to scale out, and this is
   now so common that no one even thinks of it as odd.

2. The most powerful compute engines out there within in a single box
   aren't Intel microprocessors, they're GPUs, and anyone doing really
   serious computing now uses GPUs to do it. Machine learning,
   scientific computing, etc. has become dependent on the things, and
   they're basically giant bunches of tiny processors. Ways to program
   these things have become very important.

   Oh, and your iPhone or Android device is now pretty lopsided. By
   far most of the compute power in it comes from its GPUs, though
   there are a ridiculous number of general purpose CPUs in these
   things too.

3. Even "normal" hacking on "normal" CPUs on a singe box now runs on
   lots of fairly wimpy processors. I do lots of compiler hacking
   these days, and my normal lab machine has 64 cores, 128
   hyperthreads, and a half T of RAM. It rebuilds one system I need to
   recompile a lot, which takes like 45 minutes to build on my laptop,
   in two minutes. Note that this box is both on the older side, the
   better ones in the lab have a lot more RAM, newer and better
   processors and more of them, etc.

   This box also costs a ridiculously small fraction of what I cost, a
   serious inversion of the old days when I started out and a machine
   cost a whole lot more compared to a human.

   Sadly my laptop is stalled out and hasn't gotten any better in
   forever, but the machines in the lab still keep getting
   better. However, the only way to take advantage of that is
   parallelism. Luckily parallel builds work pretty well.

Perry
-- 
Perry E. Metzger		perry@piermont.com

  parent reply	other threads:[~2018-06-28 14:51 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-26 17:54 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           ` [TUHS] PDP-11 legacy, C, and modern architectTures Theodore Y. Ts'o
2018-06-27  2:22             ` 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 [this message]
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
2018-06-29  1:02 Noel Chiappa
2018-06-29  1:06 Noel Chiappa

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=20180628104329.754d2c19@jabberwock.cb.piermont.com \
    --to=perry@piermont.com \
    --cc=tuhs@minnie.tuhs.org \
    --cc=tytso@mit.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).