Re: a dozen cpu's on a chip

On Fri, 16 May 2008 01:10:49 -0700, Robert Baer
<robertbaer@xxxxxxxxxxxx> wrote:

John Larkin wrote:
On Tue, 13 May 2008 13:57:23 -0700, Robert Baer
<robertbaer@xxxxxxxxxxxx> wrote:


John Larkin wrote:


On Tue, 13 May 2008 08:05:12 -0700 (PDT), panteltje@xxxxxxxxx wrote:



On 8 mei, 04:48, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CESEX...

I bet we'll see 256 one of these days.

John

It is of course completely of-topic, but jus tto contribute for
test :-) to
the noise, I am sure I have seen a 512 core chip several years ago.

The problem is what to do with > 6 cores.
As you al probably know Sony PS3 has a Cell processor
with one big and 6? small 'helper' processors.
Now in a multimedia application, or networking, two ways,
say signal processsing decryption decoding graphics that
will maybe use 4 cores.
It is not easy to slit a program over more then one core.
Even if threaded, it makes not always sense,
I have written threaded programs where some threads use very few
resources,
running those on a separate core woul make little sense,
Some multi media stuff uses no threads at all (Linux mplayer IIRC),
while others, xine media player for example _is_ threaded.
And this is from the POV of embedded.
Now sure, you could run some FPGA synthesize on one core,
PCB routing on the other, SPICE on a third.. however how often
do you use it at the same time.
So, and I am not even thinking Microsoft, they only have binaries for
X86 of
their OS, but the software that takes full advantage of so many cores
for a _general purpose_ OS, has, as far as I know, not been invented
yet.
And are sequential cores always the best solution? Not sure,
in the above example the decryption could be done faster by FPGA (1
clock) perhaps.

So, unless they come up with a software solution that makes full use
of those cores, perhaps the only other option is to try to up the
clock speed,
new techniques to reduce power consumption are mentioned here and
there.



My XP, not doing much right now, claims to be running 31 processes.
Add in maybe another 30 device drivers, tcp/ip stacks, and file
managers, and it would keep a 64-core cpu mostly employed.


** Well, a total of 31 processes were started, one after another (at
random)


At random? Well, it is a Microsoft product.


, but only one or two are running - and never at the same time.


Of *course* they can't run at the same time if there's only one CPU.



Take 31 cores, one for each process and the situation will be almost
perfectly identical.


Except that they can run at the same time. And there will be no task
switching. And the CPU that runs the OS will be absolutely hardware
protected from all the other processes.


Program instructions and/or data must come from the same memory.
More cores make for more data contention.


Much less. Each can have its own small ram for stack and local
variables, and a modest code cache, and there is no context switching
overhead. For a given amount of performance, hits to global cache and
to main memory would be radically reduced.


** Do not think so..each CPU "needs" to be fed; the amount of cache (for
each one) makes no difference in the amount of instructions and data
that each one demands - only the timing.
Double the "cores" means double the needs...

Cores only need to be fed if they have something to do; if not, they
can idle with zero power consumption [1] and zero bus traffic. For a
given amount of computing, N cores do it just like one core, same
nanojoules per megaflop, but with less shared cache and memory bus
traffic, and no waiting and no context switching overhead. Why does
everybody seem to assume that all the cores must be run full-blast?

John


[1} as Phil notes, silicon as we know it suffers from static leakage
as geometries scale down, so even an idle nanometer-scale CPU has high
static power consumption. A similar amount of compute power
distributed among less agressively designed cores has a great power
advantage. That's one reason that everybody is backing off on GHz and
bulking up on cores. For Pete's sake, extrapolate that trend and
*think* about where it might lead. It would take a new, probably
non-silicon, process to change that trend. But you still have to make
things out of atoms.


John

.

Quantcast