The choice the `best' process architecture for a given application may be influenced by the hardware architecture and the programming model.
Compared to the Parix implementation, PVM needs more effort to implement a mechanism for sharing work-packets among the `communicator-' and `worker tasks' executing on the same node. In Parix, all threads run in the same context and share the same global variables defined by the main program. Hence, all threads have direct memory access to the same `work packet array' maintained on a node. Memory contention is arbitrated by semaphores. In PVM, in contrast, all communication is performed via explicit message transfer -- regardless whether it is a long distance communication or a communication within tasks running on the same processor.
Typically, the PVM process architecture is designed without knowing the topology of the target hardware system. Since PVM does not provide information about the location of the tasks in the (hardware-) network, fast communication (e.g., nearest neighbor communication) is hard to implement. The virtual topologies provided by PARMACS and MPI allow more efficient mappings of tasks to processors. While such mapping functions can also be implemented by matching the Parix process descriptors to the PVM task identifiers, such programming tricks clearly violate our ultimate goal of portability.