caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: J C <jhc0033@gmail.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] thousands of CPU cores
Date: Thu, 10 Jul 2008 23:01:31 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0807102203300.13670@localhost> (raw)
In-Reply-To: <1215717356.24773.17.camel@flake.lan.gerd-stolpmann.de>



On Thu, 10 Jul 2008, Gerd Stolpmann wrote:

>
> I wouldn't take this article too seriously. It's just speculation.

I would take the article seriously.

> Just open up your mind to this perspective: It's a big risk for the CPU
> vendors to haven taken the direction to multi-core.

*Precisely*.  It also stands in stark contrast to the last 50 or so years 
of CPU development, which focused around making single-threaded code 
faster.  And, I note, it's not just one CPU manufacturer who has done this 
(which could be chalked up to stupid management or stupid engineers)- but 
*every* CPU manufacturer.  And what do they get out of it, other than 
ticked off software developers grumbling about having to switch to 
multithreaded code?

I can only see one explanation: they had no choice.  They couldn't make 
single threaded code any faster by throwing more transistors at the 
problem.  We've maxed out speculative execution and instruction level 
parallelism, pushed cache out well past the point of diminishing returns, 
and added all the execution units that'll ever be used, what more can be 
done?  The only way left to increase speed is multicore.

And you still have the steady drum beat of Moore's law- which, by the way, 
only gaurentees that the number of transistors per square millimeter 
doubles every yeah so often (I think the current number is 2 years).  So 
we have the new process which gives us twice the number of transistors as 
the old process, but nothing we can use those new transistors on to make 
single threaded code go any faster.  So you might as well give them two 
cores where they used to have one.

At this point, there are only two things that can prevent kilo-core chips: 
one, some bright boy could come up with some way to use those extra 
transistors to make single-threaded code go faster, or two: Moore's law 
could "expire" within the next 16 years.  We're at quad-core already, 
another 8 doublings every 2 years, with all doublings spent on more cores, 
gets us to 1024 cores.

I think it'll be worse than this, actually, once it gets going.  The 
Pentium III (single core) was 9.5 million transistors, while the Core Duo 
was 291 million.  Even accounting for the 2 cores and some cost to put 
them together, you're looking at the P-III to be 1/16th the size of a 
Core.  If put on the same process so the P-III runs at more or less the 
same clock speed, how much slower would the P-III be?  1/10th?  1/2?  90% 
the speed of the Core?  So long as it's above 1/16th the speed, you're 
ahead.  If your code can scale that far, it's worthwhile to have 32 P-III 
cores instead of a the dual core Core Duo- it's faster.

Yes, there are limits to this (memory bandwidth springs to mind), but the 
point is that more, simpler cores could be a performance win, increasing 
the rate cores multiply faster than Moore's law would dictate.  If we 
decide to go to P-III cores instead of Core cores, we could have 1024-core 
chips comming out in 8 years (4 doublings, not 8, to go from 4x32=64 cores 
to 1024 cores).  And remember, if Moore's law holds out for another 8 
years after we hit 1K cores, that's another 4 doublings, and we're looking 
at CPUs with 16K cores- literally, tens of thousands of cores.

If Moore's law doesn't hold up, that's going to be a different, and much 
larger and smellier, pile of fecal matter to hit the rotary air impeller.

Brian


  parent reply	other threads:[~2008-07-11  2:24 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10  5:57 J C
2008-07-10  6:15 ` [Caml-list] " Erik de Castro Lopo
2008-07-10 12:47   ` Oliver Bandel
2008-07-10 13:48     ` Hezekiah M. Carty
2008-07-10 11:35 ` Jon Harrop
2008-07-14 11:32   ` J C
2008-07-14 12:08     ` Jon Harrop
2008-07-14 17:04       ` Mike Lin
2008-07-14 17:28         ` Jon Harrop
2008-07-14 17:16       ` Richard Jones
2008-07-10 13:21 ` Jon Harrop
2008-07-10 13:44 ` Peng Zang
2008-07-10 14:00   ` Jon Harrop
2008-07-10 22:25     ` Richard Jones
2008-07-10 23:04       ` Jon Harrop
2008-07-10 23:41         ` Oliver Bandel
2008-07-11  0:17           ` Oliver Bandel
2008-07-11  9:30             ` Richard Jones
2008-09-21 19:05               ` Michaël Grünewald
2008-09-21 21:41                 ` Jon Harrop
2008-09-22  7:51                   ` Alan Schmitt
2008-09-22 19:03                     ` Jon Harrop
2008-09-22 19:49                       ` David Teller
2008-09-23  6:42                       ` kirillkh
2008-09-24 13:30                       ` [Caml-list] Link tracking Chris Clearwater
2008-09-24 15:43                         ` Jon Harrop
2008-07-11 14:53     ` [Caml-list] thousands of CPU cores Peng Zang
2008-07-15 14:39     ` Kuba Ober
2008-07-19 12:41       ` Oliver Bandel
2008-07-10 19:15 ` Gerd Stolpmann
2008-07-10 20:07   ` Sylvain Le Gall
2008-07-10 20:24     ` [Caml-list] " Gerd Stolpmann
2008-07-10 21:02       ` Sylvain Le Gall
2008-07-10 21:19         ` [Caml-list] " Gerd Stolpmann
2008-07-10 21:35           ` Jon Harrop
2008-07-10 22:39             ` Gerd Stolpmann
2008-07-15 15:57           ` Kuba Ober
2008-07-15 18:03             ` Gerd Stolpmann
2008-07-15 19:23               ` Adrien
2008-07-15 19:45                 ` Adrien
2008-07-16  8:59               ` Michaël Grünewald
2008-07-16 16:43                 ` Gerd Stolpmann
2008-07-16 11:46               ` Richard Jones
2008-07-16 18:35                 ` Erik de Castro Lopo
2008-07-17 12:48               ` Kuba Ober
2008-07-15 15:21       ` Kuba Ober
2008-07-10 20:48     ` Basile STARYNKEVITCH
2008-07-10 21:12       ` Jon Harrop
2008-07-10 23:33   ` [Caml-list] " Oliver Bandel
2008-07-10 23:43     ` Oliver Bandel
2008-07-11  6:26     ` Sylvain Le Gall
2008-07-11  8:50       ` [Caml-list] " Jon Harrop
2008-07-11  9:29         ` Sylvain Le Gall
2008-07-15 16:01           ` [Caml-list] " Kuba Ober
2008-07-13  3:17         ` Code Mobility [was Re: thousands of CPU cores] Robert Fischer
2008-07-11  3:01   ` Brian Hurt [this message]
2008-07-11 13:01     ` [Caml-list] thousands of CPU cores Gerd Stolpmann
2008-07-11 13:43       ` Jon Harrop
2008-07-11 14:03         ` Basile STARYNKEVITCH
2008-07-11 15:08           ` Jon Harrop
2008-07-11 17:28           ` Jon Harrop
2008-07-11 17:54         ` Richard Jones
2008-07-11 18:30           ` Raoul Duke
2008-07-12 17:35       ` Brian Hurt
2008-07-11 15:01     ` Peng Zang
2008-07-12  0:23       ` Oliver Bandel
2008-07-12 22:54         ` J C
2008-07-19 12:06           ` Oliver Bandel
2008-07-11 14:06 ` Xavier Leroy
2008-07-11 15:20   ` Oliver Bandel
2008-07-11 15:23   ` Bill
2008-07-11 18:14   ` Mattias Engdegård
2008-07-12 23:05   ` J C

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=Pine.LNX.4.64.0807102203300.13670@localhost \
    --to=bhurt@spnz.org \
    --cc=caml-list@yquem.inria.fr \
    --cc=info@gerd-stolpmann.de \
    --cc=jhc0033@gmail.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).