How Many Processor Cores Are Enough?
|
From: Terje Mathisen on 12 Oct 2006 07:16 Nick Maclaren wrote: > In article <1160641396.087623.67890(a)m73g2000cwd.googlegroups.com>, > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > |> 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. Indeed. There are even codes which are partly parallelisable, and for which it makes economic sense to split it into multiple phases: From oil exploration: Run the first part on a huge shared-memory machine, capable of holding it all, to generate a non-uniform grid. Take the result of part one and distribute it across 512 nodes, each having two cpus (which can again be multi-core). From prime number searches: The first stage can be run on any number of cpus, while the final sieving needs a very large machine indeed. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen on 12 Oct 2006 07:21 Tim Bradshaw wrote: > On 2006-10-12 11:14:10 +0100, kenney(a)cix.compulink.co.uk said: > >> Actually you can, the speed of light depends on the medium it is >> travelling in. C is the speed of light in a vacuum and should only be >> used for that. > > I'm sure Dennis meant the speed of light in vacuo: I certainly did. > I am sure Dennis really appreciated being told about the speed of light, and how it varies in different materials. Suddenly he'll understand how his measurements never seemed to agree with the official ~3e8 m/s! Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen on 12 Oct 2006 07:28 Nick Maclaren wrote: > In article <1160646792.020194.135340(a)i42g2000cwa.googlegroups.com>, > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > |> > |> Combinatorial problems are available, that can soak up any number of > |> processors. Take, for example, planning a route for your vacation, > |> using a super-sophisticated successor of Microsoft Mappoint. > > It has always been trivial to soak up an arbitrary amount of computer > time. So what? > > Ifr you look at those problems in more depth, you will find that an > infinitesimal number of them justify the use of a full search; in > practice, all that is needed is a near-optimal solution. That is > why many 'insoluble' problems have been solved commercially for over > 4 decades. I happened to take part in an Orienteering competition last evening, where the task was not to run as fast as possible, but to visit as many control points as possible (out of 25) in a fixed time (45 minutes). To make the planning stage even more interesting, the controls had different points ratings, from 1 for easy controls close to the start/finish area, up to 5 for a few controls far away. It is very easy to show that a human brain has no possibility of working out an optimal solution to this problem, particularly since you have to solve the problem while the clock is already ticking, i.e. we got the map at the start signal. However, everyone taking part knows the same thing as Nick states here, that an approximate solution that takes 5 seconds to work out is _much_ better than a near-perfect solution that takes 5 minutes, or a perfect solution that takes 5 days/months/years. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: ranjit_mathews@yahoo.com on 12 Oct 2006 09:41 Nick Maclaren wrote: > In article <1160646792.020194.135340(a)i42g2000cwa.googlegroups.com>, > "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: > |> > |> Combinatorial problems are available, that can soak up any number of > |> processors. Take, for example, planning a route for your vacation, > |> using a super-sophisticated successor of Microsoft Mappoint. > > It has always been trivial to soak up an arbitrary amount of computer > time. So what? So, as long as there are a few popular applications that do nifty stuff quickly using many processors, not all applications would have to be heavily parallelized for people to go for many processors. > Ifr you look at those problems in more depth, you will find that an > infinitesimal number of them justify the use of a full search; in > practice, all that is needed is a near-optimal solution. That is > why many 'insoluble' problems have been solved commercially for over > 4 decades. You can get a near-optimal solution from Mapquest. But then, you can't tell Mapquest you like, say, lightly traveled 2 lane country roads. ... and this is but one example, there might be many other applications that developers have barely started dreaming* of, that can put many processors to good use. * At the time the Cray XMP was released, would you have been able to dream of many of the current uses for PCs surpassing it in computing capacity? > > > Regards, > Nick Maclaren.
From: Nick Maclaren on 12 Oct 2006 10:26
In article <1160660486.912240.193460(a)k70g2000cwa.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> |> > It has always been trivial to soak up an arbitrary amount of computer |> > time. So what? |> |> So, as long as there are a few popular applications that do nifty stuff |> quickly using many processors, not all applications would have to be |> heavily parallelized for people to go for many processors. If wishes were horses, beggars would ride. |> You can get a near-optimal solution from Mapquest. But then, you can't |> tell Mapquest you like, say, lightly traveled 2 lane country roads. ... |> and this is but one example, there might be many other applications |> that developers have barely started dreaming* of, that can put many |> processors to good use. There might, indeed, be a way of using GM techniques to insert bat genes into pigs, and get the latter to fly. |> * At the time the Cray XMP was released, would you have been able to |> dream of many of the current uses for PCs surpassing it in computing |> capacity? Yes. I did. And, more interesting, there is documentary evidence that some people older and more far-sighted than I am did so in the 1950s. Regards, Nick Maclaren. |