From: Nick Maclaren on

In article <1160538034.947626.271760(a)m7g2000cwm.googlegroups.com>,
"ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes:
|> Nick Maclaren wrote:
|> > On most CPUs, it isn't as simple as 50% more GHz is 50% more operations
|> > per cycle, even in artificial codes that don't access memory or do I/O.
|>
|> How about codes that do access memory but not I/O and are memory
|> limited - i.e., limited by how fast loads and stores can go?

A 50% clock rate increase would make essentially no difference;
memory speeds do NOT increase pro rata to CPU speeds.

As I said, look up RC delay. Until and unless someone can get
opto-electronics working for internal chip 'wiring', that will be
the cause of the problem. I found that out by asking here, and
spent a couple of happy hours reading up about it - is a damn close
to an insoluble problem.


Regards,
Nick Maclaren.
From: ranjit_mathews@yahoo.com on
Dennis M. O'Connor wrote:
> <ranjit_mathews(a)yahoo.com> wrote ...
> > Dennis M. O'Connor wrote:
> >> <ranjit_mathews(a)yahoo.com> wrote ...
> >> > No, since for a given design, if you know ops/GHz, you can estimate
> >> > what the ops would be at (say) 50% more GHz.
> >>
> >> No, you can't, unless you can somehow make all
> >> the other components in the system go faster too.
> >
> > Naturally. Would you expect Gene Amdahl or someone like him to build a
> > new machine with higher compute performance but the same I/O? He would
> > scale up everything unless the new machine is targeted at a different
> > problem.
>
> You can't scale up the speed of light.

No, but you can reduce the distance a signal has to travel. What
happens when you shrink a 3cm trace to 1.5 cm? Electrons go no faster
but the distance they have to travel gets reduced.

> Propagation delays matter, on-chip and off.

Which delays matter depends on what your problem is. If you put
together a static dataflow network to process a certain stream of data
and if quadrupling the size of your dataflow network (something like a
systolic array in terms of hardware terminology) increases the time for
the data coming in at one end to get crunched and appear as results on
the other end, that might not matter at all if what you're looking for
is the ability to crunch a larger problem size.

> You don't seem to know much about
> computer architecture or physics.
>
> I more strongly suspect you are a troll.

Alberich at your service:-)

> --
> Dennis M. O'Connor dmoc(a)primenet.com

From: Tim Bradshaw on
On 2006-10-11 14:55:27 +0100, "ranjit_mathews(a)yahoo.com"
<ranjit_mathews(a)yahoo.com> said:

> Sun's big boxes are descended from the E10K which was originally
> developed by Floating Point Systems; in an E10K, a processor was closer
> to its local RAM than to another processor's L2 cache. The opposite is
> true in the case of the IBM Regatta (p690). Each system board in an
> E10K was not particularly bigger than a large PC motherboard and 4
> memory boards were plugged right into each system board, so it doesn't
> seem that a processor's local RAM could have been a few feet away.

Yes thank you I'm quite familiar with the E10k, although I think the
current SF boxes are reasonably different designs (certainly much
better in terms of maintainability etc). The issue is that *most of
the memory of the system* is more than a foot away from any given core
in the system, because most of the memory of the system is not on the
same board as any given core.

--tim

From: ranjit_mathews@yahoo.com on
Jon Forrest wrote:
> Today I read that we're going to get quad-core processors
> in 2007, and 80-core processors in 5 years. This has
> got me to wondering where the point of diminishing returns
> is for processor cores.

> Where do you think the point of diminishing returns might
> be?

For NUMA optimized parallel codes, far beyond 80. So, a better question
is beyond what core count the number of codes that can use the cores
will fall to an infinitesmally small number.

From: Nick Maclaren on

In article <1160641396.087623.67890(a)m73g2000cwd.googlegroups.com>,
"ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes:
|> Jon Forrest wrote:
|> > Today I read that we're going to get quad-core processors
|> > in 2007, and 80-core processors in 5 years. This has
|> > got me to wondering where the point of diminishing returns
|> > is for processor cores.
|>
|> > Where do you think the point of diminishing returns might
|> > be?
|>
|> For NUMA optimized parallel codes, far beyond 80. So, a better question
|> is beyond what core count the number of codes that can use the cores
|> will fall to an infinitesmally small number.

I am tempted to quote Dr Samuel Johnson on remarriage here, but shall
refrain.

That applies only to codes that have very small working sets and
perform very little communication between threads; while there are some
such, it turns out to be VERY hard to cast more than a VERY few problems
into that form.


Regards,
Nick Maclaren.