Newsgroups: comp.parallel.pvm
From: pdinda@cs.cmu.edu (Peter A Dinda)
Subject: Re: PVM on Windows PCs?
Organization: School of Computer Science, Carnegie Mellon
Date: 28 Aug 1994 15:21:39 GMT
Message-ID: <33qa23$3v0@cantaloupe.srv.cs.cmu.edu>


This discussion seems to be going nowhere.  I'm not even remotely interested
in a Windows port of PVM - it is just very premature to say that can't be
done before even examining the facilities that Windows offers.  An 
implementation of PVM for Windows would probably only offer limited 
functionality, but that's no different from some other PVM implementations.
Even an implementation that would take over the machine for a single
PVM process would be interesting:  Keep in mind that most PC are used
for only eight hours out of the day.


In article <33od2c$ccl@falcon.ccs.uwo.ca>,
Crispin Cowan <crispin@csd.uwo.ca> wrote:
>In article <33m1qf$sm6@cantaloupe.srv.cs.cmu.edu>,
>Peter A Dinda <pdinda@cs.cmu.edu> wrote:
>>developed set of rules for using the processor and DOS, the DOS Protected
>>Mode Interface (DPMI), V8086 is used by Windows to permit multiple
>>(16, I believe) 32 bit sessions to exist.  These are scheduled in
>So you can have 16 pre-emptively scheduled tasks, so long as they think
>that they're DOS programs.  Greaaat :-)

How many PVM processes do you want to run on a single machine?

[comments about lack of interprocess protection making possible wrong answers]

>Other than it makes debugging more difficult.  But we're not talking
>about an isolated cluster running a single PVM job, we're talking about
>a Windows environment.

I believe we were talking about PVM on Windows.  I don't think we've
defined the capabilities and limitations of such a beast.  Perhaps running
on an isolated cluster should be one of the limitations.

>>PVM communication primitives may be similar to an extreme subset of
>>NX, but you seemed to be talking about Unix signals and rsh.
>I never said PVM was similar to the UNIX primitives.  The PVM group
>went to a lot of effort to map MPP-style communications into UNIX,
>which is why PVM is a significant piece of work.

I agree with that.  However, more importantly, they defined an interface
and the semantics of message passing using that interface.   As long
as an implementation provides that interface and conforms to the
semantics, it *is* PVM.           
 
>>Actually this is starting to bug me.  If these issues are trivial on
>>the Paragon and T3D, then why are the PVM implementations for these platforms
>>incomplete and significantly slower than the native message passing? 
>The native primitives were tightly coded to get optimal performance out
                                                 ^^^^^^^^^^^^^^^^^^^
NX can barely get 1/2 the hardware bandwidth of a pgon link.

>of a specific piece of hardware.  PVM was written to be portable and
>inter-operable independent of the hardware.  That, plus the software
>overhead of just adding another layer to the calling interface to
>something as simple as message passing, and a factor of 2 degredation
>doesn't seem unexpected.

By your own argument, PVM should be "trivial" to implement on top of NX
because it's modeled after MPP communications interfaces.  Although 
I would expect performance degradation using the init/pack/send/rcv/unpack
calls, It's very surprising to find it using psend/precv, which would
seem to be mappable directly into isend/crecv.  

Anyway, I'm not sure where we are going with these aside on the pgon.  
Back to PVM on Windows:  I agree with you that such an implementation
would be difficult and that perhaps only a partial implementation would
be possible.  However, I don't see why you think such implementation is   
impossible or undesirable.

-- 
Peter A. Dinda (pdinda@cs.cmu.edu)
Graduate Student, School of Computer Science, Carnegie Mellon University

