Newsgroups: comp.parallel.pvm
From: Greg Baker <gbaker@walleroo.rp.csiro.au>
Subject: Re: Q: pvm & non C/fortran programs
Organization: CSIRO Division of Radiophysics/Australia Telescope National Facility
Date: Tue, 3 Sep 1996 05:24:54 GMT
Message-ID: <85afv8yxuh.fsf@walleroo.rp.CSIRO.AU>

kroemer@alhena.itp.uni-hannover.de (Eike Kroemer) writes:
> Hello,
> 
> I could need some advice:
> 
> here we have a relatively big piece of software that shall be ported to
> Unix (and expanded) in the near future. This software consists of some
> independently running processes (possibly on different machines of a
> cluster) that need to send messages to oneanother. Currently these
> messages are stored in temporary disk files.
> We now think about other mechanisms of message transfer and ran across
> pvm, so here the questions:
> 
> 1) will there be a performance increase? The number of files written during
>    one simulation is several thousands, average size ~100 bytes.

I should expect a blinding speed improvement using PVM to handle this
rather than temporary files under NFS.  On the other hand, if the
files are memory mapped and the processes are running all on the same
SMP machine, then you might lose a teeny bit.  I expect you'll get a
bit of an improvement.

Even if you were going to just stay the same, you will have a much
more maintainable system since there is a very clear API in the PVM
for message passing.  It will also make it much easier to port it to
other architectures.  Assuming you don't write naughty Ada,  if you
rewrite to use PVM,  then you have an automatic port to WinNT, Unix
and probably OS/2.  Possibly others,  too.  (All of which could be in
the cluster at the same time!)


> 2) the program is written in ADA, is it possible to write only the
>    subroutines concerning message transfer in C and link with the pvm_lib
>    or does pvm require to compile the entire application in it's environment?
> 

The answer is : you can write everything in Ada. Currently the C
function calls for the packaging of data are of the form

  pvm_pkfloat ( float * data , int count,  int stride );

If you're slightly crazy,  you could do some very-quick-and-dirty
bindings such as...

package Pvm is
  procedure Pack_Float ( Data : in System.Address ; 
                             Count : in Interfaces.C.int ;
                             Stride : in Interfaces.C.int := 1);
  pragma Import(C,Pack_Float,"pvm_pkfloat");

 etc.
end Pvm;

which will do you fine,  except that you'll find yourself doing things like

  Pvm.Pack_Float(The_Data'Address,The_Data'Last - The_Data'First + 1);


That's about as bad as it gets, though.  And in fact, it could be improved
enourmously with a very slightly thicker binding...

  procedure Pack ( Data : array <> of Real ) is 
  begin
       Pack_Float (Data'Address, Data'Last - Data'First + 1);
  end;
  pragma Inline(Pack);

or something similar. Most of the other bindings will be reasonably
straightforward, and there's scope for making them really pretty.  For
example :
   int   pvm_mkbuf ( int encoding ) ;

turns very nicely into 

   type Encoding_Type is (DataDefault,DataRaw,DataInPlace)
   for Encoding_Type use (DataDefault=>0, DataRaw => 1, DataInPlace=>2);
   for Encoding_Type'Size use Interfaces.C.int'Size;

   type BufferId is new Interfaces.C.int;

   function Make_Buffer ( Encoding : Encoding_Type := DataDefault) 
                                       returns BufferId;
   pragma Import(C,Make_Buffer,"pvm_mkbuf");

 or better still,

   procedure Make_Buffer ( Buffer : in BufferId;
                           Encoding : Encoding_Type := DataDefault )

 with a little bit of glue code.


The PVM API consists about 50 function calls,  many of which just do
the same thing with different types.  I wouldn't think doing some nice
Ada bindings would be at all difficult - I'd estimate about a week or
two's work for someone familiar with doing Ada-C bindings and who
already knew the PVM.  

I was vaguely intending to do this very job myself in the near future,
but if somebody else is,  then great.  (Of course,  if you want to
contract the work out to me... :-)  )

Hope this helps.

-- 
Gregory D. Baker        gbaker@rp.csiro.au         CSIRO Radiophysics 
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
   - predictions of the future - quantum computers - silly poetry  -
   - the "langue musicale universale" (Solresol)  revival project  - 
   - - - - - - - - http://www.rp.csiro.au/~gbaker  - - - - - - - - -
I'm an eccentric mathematician/IT guru/communicator,  and I'm looking
               for a new job in Sydney,  Australia.

