flaig / sanctacaris.net wrote:
> 
> Higher-level languages, by contrast, contain (or at least may contain)
> structures such as MAP which tell the compiler/interpreter: "This
> refers to an entire block of data" and may be extended to: "So distribute
> the workload as you think fit." This would not even require any analysis
> but just a fistful of code in the part of the compiler that handles the
> respective statement.

Would that it were this simple.  A "map" function operates on a list, 
but what are the potential relationships between members of any list? 
In most cases it's very hard to be sure.  And if you can't prove 
mathematically, at compile (or even execution) time, that there are zero 
interactions between the list members, then your compiler had best not 
inject any threaded code.

>>"You can't get blood from a stone." The only thing that is "like
>> having 29 extra cpus" is actually having 29 extra CPUs. :)
> 
> You can, if and only if ("iff") the net workload of the thread is
> negligible  when compared to the administrative overhead, ...

I read this as saying, "if your threading overhead is so rediculous that 
it consumes 29/30ths of your CPU time," then you are better off not 
using threads."  This is certainly true, but it misses the point.  Good 
threaded software design minimizes threading overhead, thus a 
(potential) 30x speedup indicates a poor design, not a poor threading 
system.

> For bioinformatics work, I'd opt for the 29 extra cpus.

Of course, but can you get 30x work out of them?  I suspect that in 
bioinformatics, many of the "big" problems are easily isolated into 
non-communicating work units.  I'm running the World Community Grid 
client, which is currently cranking on the Human Proteome Folding 
Project.  My computer, along with thousands more, handles its job with 
relatively little coordination from the central work server at IBM.  For 
this system, threading would be a waste.

But, there are other not purely compute-bound problems that require more 
intricate and fine-grained scheduling to achieve decent scaling.

-- 
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>