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: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] thousands of CPU cores
Date: Sat, 12 Jul 2008 13:35:48 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0807121300000.13670@localhost> (raw)
In-Reply-To: <1215781305.28798.19.camel@flake.lan.gerd-stolpmann.de>



On Fri, 11 Jul 2008, Gerd Stolpmann wrote:

> Well, it is an open question whether this alternative holds. I mean
> there is a market, and if the market says, "no we don't need that
> multicore monsters", the chip companies cannot simply ignore it.

You're still assuming the chip companies *have a choice*.  And that 
there for, if the markets are just demanding enough, they'll go "oh, well, 
we didn't realize how important this is to you- we'll just go back to 
single threaded chips now..."  My point is that *all* of the chip 
companies are not this stupid, and if there was a choice, most of them 
wouldn't have choosen this route.  If there was one holdout, one chip 
company not going multicore, I'd probably agree with you.  I don't see the 
holdout (not among the chip makers at all pushing the performance 
envelope- yeah, a number of players in the embedded market aren't going 
multicore).

> Well, there is a another option for the chip industry. Instead of
> keeping the die at some size and packing more and more cores on it, they
> can also sell smaller chips for less. Basically, this alternate path
> already exists (e.g. Intel's Atom). Of course, this makes this industry
> more boring, and they would turn into more normal industrial component
> suppliers.

This has two problems, and "boredom" isn't one of them:

1) It undercuts the main selling point to get people to upgrade- increased 
performance.  We're used to buying new CPUs every yeah so often because 
the ones on the market are significantly faster than the ones we have 
(although the definition of "significantly faster" has slowly gone down 
over the years).

One of the ways the next generation was made faster was by throwing more 
transistors at the problem (allowing you to do more work per clock cycle). 
The other way was clocking the CPUs faster, but that also seems to be 
hitting problems (I'm not sure if the Power 6 means we may be exiting the 
clock speed drought, or if it's just a "revenge of the RISC" (i.e. 
something specific to the Power architecture that allows it to be clocked 
~2x as fast as the x86).

In either case, you're going to see a drop in the unit sales of "high end" 
CPUs.  And the third world isn't going to help with this- when I first 
became a professional software engineer, I bragged about having access to 
400MHz CPUs with 64M of ram- basically, computers with the horse power of 
a OLPC.

2) It really cuts into margins.  Generally, the amount of money the chip 
maker gets from selling a single $200 CPU is greater than the amount they 
get from selling 2 $100 CPUs, let alone 8 $25 CPUs.

And those are just the problems from the CPU vendor's perspective.  Now, 
lets look at this from the Software Developer's perspective:

We've fallen solidly off the Clock Speed ramp- even if we ignore the P4's 
inflated clock rates, it's been over 8 years since we've hit 1GHz, we 
should be at 8GHz or more now.  Now the 2-3GHz we're at.  And if we can't 
throw more transistors at the problem, CPUs simply aren't getting 
significantly faster.  Oh, there may be percentage-point gains now and 
again, but basically, where we are is where we'll stay.

Moore's Law just ended, from the software developers perspective.

No longer will the increasing speed of CPUs offset the increasing bloat 
and slowness of our code.

This turns out to be just a radical change of a different sort.

Brian


  parent reply	other threads:[~2008-07-12 17: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   ` [Caml-list] thousands of CPU cores Brian Hurt
2008-07-11 13:01     ` 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 [this message]
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.0807121300000.13670@localhost \
    --to=bhurt@spnz.org \
    --cc=caml-list@yquem.inria.fr \
    --cc=info@gerd-stolpmann.de \
    /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).