From: Terje Mathisen on
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
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
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

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

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.