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: Tue, 17 Jan 2017 11:55:04 -0800	[thread overview]
Message-ID: <cbd9b78839d2f75f95c9f7f4048b88b3a3281a9c@webmail.yaccman.com> (raw)
In-Reply-To: <512ABFFE-C238-45CA-9C43-CF9A84E4DE49@tfeb.org>

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

Ah, the notion of clock speed...   For 75 years we have designed
circuits with a central clock.   For the last 10 years, people have
gone to great length to make a billion transistors on a chip operate
in synchrony, using techniques that are getting sillier and sillier
and don't provide much benefit.  For example, at lower voltages and
thinning wires, chips become dramatically more temperature sensitive,
so all kinds of guard bands and additional hardware gook is required
to make the chips function correctly.   There are some very
interesting technologies that are not clock based, scale well, are low
power, and perform well over wide variations of voltage and
temperature,   The problem is they would require a completely new
set of design tools, and the few players in this area don't want to
rock the boat.

It's not necessary to go that far, however.  Our chip has no global
signals and will probably be faster than 6 GHz.

Steve

----- Original Message -----
From: "Tim Bradshaw" <tfb@tfeb.org>This doesn't mean that the process
will continue: eventually you hit physics limits ('engineering' is
really a better term, but it has been so degraded by 'software
engineering' that I don't like to use it).  Obviously we've already
hit those limits for clock speed (when?) and we might be close to them
for single-threaded performance in general: the current big (HPC big)
machine where I work has both lower clock speed than the previous
 one and observed lower single-threaded performance as well, although
its a lot more scalable, at least in theory.  The previous one was
POWER, and was I think the slightly mad very-high-clock-speed POWER
chip, which might turn out to be the high-water-mark of
single-threaded performance; the current one is x86.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170117/6232d531/attachment.html>


  parent reply	other threads:[~2017-01-17 19:55 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
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 [this message]
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=cbd9b78839d2f75f95c9f7f4048b88b3a3281a9c@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).