[fpc-devel] Light weight threads for FPC

[Mark Morgan Lloyd]

Michael Schnell wrote:
>> For clusters there is already a de facto standard: MPI. It works with
>> FPC.
>>
>>   AFAIK OpenMP and MPI work well together and are separate.
>>   
> Right now my concerns are not about how and what features should be 
> implemented (in the libraries), but only about how they are presented by 
> _language_extensions. (And about the interface the libraries offer to 
> the user)
> 
> Here an as broad as possible range of ways to do parallel processing 
> should be allowed - hiding the details (i.e. if using MPI or OpenMP or 
> something else) should be hidden in the implementation in the library in 
> a way as transparent as possible to the user.

I think that modifying the language to incorporate MPI would be extremely 
difficult and would be so near the bleeding edge of computer science that the 
next person to do it would design something equally good but utterly 
different. As I understand it MPI is generally used to pass a result vector 
between nodes, at that point determining the extent of the vector and when 
it's ready for transfer is going to be highly application-specific i.e. a 
library issue.

Looking elsewhere in this thread, I believe that the number of CPUs can be got 
as part of the thread-affinity API which I believe would be of use in TThread, 
at worst if you set the affinity to 0xffffffff you get back a vector showing 
which CPUs actually exist.

However an interesting issue is that on some architectures the list of 
available CPUs can have "holes" in it, e.g. I've got a system here with CPUs 
0, 1 4..15 available.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]