Re: How many hardware threads?

[Gene <gene.ressler@gmail.com>]

On Jul 12, 3:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 11 Jul 2010 20:47:41 -0400, Peter C. Chapin wrote:
> > I see a couple of difficulties with writing effective parallel programs
> > for "ordinary" applications (that is, applications that are not
> > embarrassingly parallel). One difficulty is load balancing: how can one
> > decompose a problem to keep all processors reasonably busy? The other
> > difficulty is scalability: how can one design a single program that can
> > use 2, 4, 16, 128, or more processors effectively without knowing ahead
> > of time exactly how many processors there will be? I'm not an expert in
> > Ada tasking but it seems like these questions are as big a problem for
> > Ada as they are for any other language environment.
>
> Back in 90's, during the era of transputers, concurrent algorithms were
> decomposed knowing in advance the number of processors and the topology of
> the network of. (Unlike to multi-cores the transputers didn't share memory,
> they communicate over serial links connected physically) That time the
> consensus was that the problem is not solvable in general. So you designed
> up front both the algorithm and the topology.
>
> > I'm not an expert in
> > Ada tasking but it seems like these questions are as big a problem for
> > Ada as they are for any other language environment.
> > I'm not looking for a solution to all tasking problems here. But there
> > is one feature that seems like a necessary prerequisite to such a
> > solution. The language (or its standard library) needs to provide a
> > portable way for the program to determine how many hardware threads are
> > available.
>
> Well, maybe, but I don't think it would bring much. Especially because
> normally cores support multi-tasking. It would be more important for the
> architectures with the cores that do not (GPU etc).
>
> BTW, "hardware thread" = core? processor? ALU + an independent memory
> channel? etc. It is quite difficult to define and the algorithm's
> performance may heavily depend on the subtleness. ARG would say, look, it
> does not make sense for all platforms, forget it.
>
> > I'm about to write a simple program that decomposes into parallel,
> > compute-bound tasks quite nicely. How many such tasks should I create?
>
> Back in time it was popular to make it adaptive. I.e. you monitor the
> performance and adjust the size of the working threads pool as you go. I
> remember some articles on this topic, but it was long long ago...
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Dmitry has it exactly right.  When a "hardware thread" can be anything
from a fraction of a core to a node on an Ethernet-connected cluster,
how many you have is not such an important question.

Guessing high and allowing the OS to sort things out has severe
limitations.  What to guess?  4? 16? 256?

When there is only a small number of independent performance control
variables, e.g. one in the case of a common thread pool, the self-
monitoring and adjustment scheme is the only one with legs.

Other multi-threading models like work stealing present a more complex
tuning problem.  Evolutionary (genetic) algorithms ought to be a
powerful way for software to adapt to its own environment. Is there
anyone doing work on this?