[fpc-devel] Light weight threads for FPC
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Mon Dec 17 14:54:38 CET 2007
Michael Schnell wrote:
>> For clusters there is already a de facto standard: MPI. It works with
>> 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
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]
More information about the fpc-devel