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
next prev 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