How Many Processor Cores Are Enough?
|
From: ranjit_mathews@yahoo.com on 10 Oct 2006 12:07 Nick Maclaren wrote: > In article <1160477501.173323.39850(a)h48g2000cwc.googlegroups.com>, > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > |> > |> If your competitor ships a computer with a 1.6GHz processor and > |> DDR2-533 RAM and you figure that they can get their processor to run at > |> 3.2Gz by the time DDR3-1066 RAM becomes mainstream, you know they'll be > |> able to compress or run a DOM parser about twice as fast, don't you? > > No. It would be "no" only if you have some sure-fire way of determining that your competitor is incapable of scaling up all the parts in their system along with the processors they use. > It's not what you don't know that causes the trouble, it's what > you know that ain't so. > > > Regards, > Nick Maclaren.
From: Tim Bradshaw on 10 Oct 2006 12:19 On 2006-10-10 16:53:52 +0100, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> said: > 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. But you *can't* make all the other components go faster. Or rather, you can (perhaps) but you can't then hide the latency. The history of computer architecture for at least the last 20 years (and probably much longer) has substantially been a history of dealing with not being able to just crank a machine faster. --tim
From: Nick Maclaren on 10 Oct 2006 12:27 In article <1160496420.908302.5740(a)b28g2000cwb.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> > |> |> > |> If your competitor ships a computer with a 1.6GHz processor and |> > |> DDR2-533 RAM and you figure that they can get their processor to run at |> > |> 3.2Gz by the time DDR3-1066 RAM becomes mainstream, you know they'll be |> > |> able to compress or run a DOM parser about twice as fast, don't you? |> > |> > No. |> |> It would be "no" only if you have some sure-fire way of determining |> that your competitor is incapable of scaling up all the parts in their |> system along with the processors they use. No, it wouldn't. Read what YOU said. "You know they'll" is short for "you know they will" and not "you cannot be sure that they will not". Regards, Nick Maclaren.
From: ranjit_mathews@yahoo.com on 10 Oct 2006 12:33 Tim Bradshaw wrote: > On 2006-10-10 16:53:52 +0100, "ranjit_mathews(a)yahoo.com" > <ranjit_mathews(a)yahoo.com> said: > > > 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. > > But you *can't* make all the other components go faster. The components that need to go faster are the ones that matter to the problem at hand. If the ones that matter to a given problem are the processor, RAM and communication links between processors, then if you maintain a constant ratio of speed of RAM to the speed of those other components, you can make them go faster. You can't get, say, gigabit Ethernet or Infiniband to go faster but their speed, or lack thereof, might not affect your problem. > Or rather, > you can (perhaps) but you can't then hide the latency. If you can keep their latencies constant when measured in ticks (a unit of time that changes in inverse proportion to frequency), then you don't need to hide latency to any greater extent than you used to need to hide it. For example, try to use RAM with the same timings (same number of bus cycles for an access).. > The history of > computer architecture for at least the last 20 years (and probably much > longer) has substantially been a history of dealing with not being able > to just crank a machine faster. > > --tim
From: Nick Maclaren on 10 Oct 2006 12:48
In article <1160498037.534827.230500(a)i3g2000cwc.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> |> The components that need to go faster are the ones that matter to the |> problem at hand. If the ones that matter to a given problem are the |> processor, RAM and communication links between processors, then if you |> maintain a constant ratio of speed of RAM to the speed of those other |> components, you can make them go faster. You can't get, say, gigabit |> Ethernet or Infiniband to go faster but their speed, or lack thereof, |> might not affect your problem. Indeed. Quite right. And, if pigs could fly, I would be able to ride one to work. |> If you can keep their latencies constant when measured in ticks (a unit |> of time that changes in inverse proportion to frequency), then you |> don't need to hide latency to any greater extent than you used to need |> to hide it. For example, try to use RAM with the same timings (same |> number of bus cycles for an access).. Indeed. Please do. When you have failed, you should look up a few books on computer design, specifically with regard to RC delay. Regards, Nick Maclaren. |