HPC: Using Message Passing to distribute threads

[Aluminium Oxide]

Forgive me if I am suggesting that we reinvent the wheel, but I have a
problem with a potentially simple solution.

It concerns the difficulty of adapting an application to use a parallel
computing system, such as with MPI or PVM.

I would like help possible to write a simple (heh heh) compiler
directive, or header, or a wrapper function which allows one to add a
tag or wrap a function call to a function which will be called
iteratively to spawn not just a new thread, but a new thread ***which
can be passed to another node*** in a parallel computer system?

This seems like a very simple and elegant method by which
non-parallelised code can be adapted to a parallel architecture.

My C, and my understanding of threading is very limited, and I've never
written  any kernel code. However, I will try and give an example:

The adaption process would simply become

o   #include <pvmwrap.h> /* Add support for a parallel computing thread
call */
o   locate higher-level functions which are computationally intensive
and will be called iteratively;
o   replace the raw function call with a pvmwrapped call.



Eg.,
/*A module to calculate n! for the first 1000 numbers*/

 int number;
 long double number_factorial;
 long double factorial (int number) {.....}
.....
 scanf("%d",number);
 for (i=0;i==number;i++,number_factorial=(factorial(number))) {
   printf ("%d factorial = %d",number_factorial;
 }
....


would become
 
#include <pvmwrap.h>

 int i,number;
 long double number_factorial;
 long double factorial (int number) {.....}
.....
 scanf("%d",number);
 for (i=0;i==number;i++,pvmwrap(number_factorial=(factorial(number)))) {
   printf ("%d factorial = %d",pvmwrap(factorial(number);
 }
....

pvmwrap would have the necessary calls via the message passing protocol
to create the thread on the next available node, rather than on the
local system, and return the result to the caller. pvmwrap will need to
perform type identification of the variables, or targets of pointers,
and then declare these on the executing node first, to permit execution
without having to specifically code these declarations as parallelised
(which would greatly complicate the adaption to parallelism). The few
cycles used to perform these type identifications each iteration are
negligible compared with those of the wrapped function itself.

What say ye?

Damien Miller
===================================
                 Sub POSIX lumen
           orac000@...
                 [phone]
   au.geocities.com/orac000000/bsd.html
===================================
--
  Aluminium Oxide
  orac000@...

--
http://www.fastmail.fm - Choose from over 50 domains or use your own

_______________________________________________
freebsd-hpc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hpc
To unsubscribe, send any mail to "freebsd-hpc-unsubscribe@..."

[Brooks Davis]

[Dropped irrelevent mailing lists.  In general CCing lists at multiple
sites is bad form].

On Tue, Feb 14, 2006 at 03:58:53PM +1030, Aluminium Oxide wrote:

> Forgive me if I am suggesting that we reinvent the wheel, but I have a
> problem with a potentially simple solution.
>
> It concerns the difficulty of adapting an application to use a parallel
> computing system, such as with MPI or PVM.
>
> I would like help possible to write a simple (heh heh) compiler
> directive, or header, or a wrapper function which allows one to add a
> tag or wrap a function call to a function which will be called
> iteratively to spawn not just a new thread, but a new thread ***which
> can be passed to another node*** in a parallel computer system?
>
> This seems like a very simple and elegant method by which
> non-parallelised code can be adapted to a parallel architecture.

That you're describing is functionally if not syntatcicaly identical to
OpenMP.

http://en.wikipedia.org/wiki/OpenMP

GCC's GOMP project is creating such a implementation for SMP systems at:

http://savannah.nongnu.org/projects/gomp/

Note that this won't work for a cluster, there have been implementations
of OpenMP on top of message passing libraries, but codes and clusters
where such implementations make sense given the communication overhead
are rare.

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4