Re: [9fans] parallel programming in Plan 9

Re: [9fans] parallel programming in Plan 9

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

I don't believe that there is anything inherent in Plan 9 that
makes writing parallel programs easy, especially if the machines
in question are not shared memory machines.  We have a thread
library that is different, but not significantly so, from other
thread libraries.  Alef had constructs in it for parallel programming
but it died from lack of support/use.

The only thing we do have is an easy way to import resources from
other machines.  However it requires that the interface looks like
a file system and you can only push that so far.  It's been useful
for decomposing a larger system in to a bunch of servers that can run
on disparate systems/architectures.  However if you have to pass
messages twixt programs, it doesn't really help deciding what
the messages should look like or how to marshal them.

[-- Attachment #2: Type: message/rfc822, Size: 2681 bytes --]

From: James Horey <jhorey@unm.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] parallel programming in Plan 9
Date: Wed, 18 Feb 2004 14:02:07 -0700
Message-ID: <4033D2CF.3030208@unm.edu>

Hi,

Does someone mind explaining to me the advantages of using Plan 9 to
write/run parallel programs over say writing a "traditional" parallel
program using MPI? I read several things mentioning the higher
abstraction that private namespaces provide over explicit message
passing, but frankly I am not sure how to apply that idea efficiently to
remove explicit message passing. For instance, what would efficiently
replace MPI_Reduce? Also, I've briefly read something about Alef, but
there doesn't seem to be much talk about it. Is that language still
actively used in this community? Perhaps my brain isn't cooperating with
me today, so I would appreciate any help. Thanks!

-James Horey

Re: [9fans] parallel programming in Plan 9

[rog]

> However if you have to pass
> messages twixt programs, it doesn't really help deciding what
> the messages should look like or how to marshal them.

...  although i've found that using 9p helps focus the mind on to what
messages are really necessary, and the conventional textual
representation of messages lends itself well to

a) ease of explanation/documentation and
b) proper separation of interface from implementation on both ends of
the connection.

this contrasts with RPC-style marshalling where the RPC interface is
often taken directly from the procedural interface on the server,
which is not necessarily the way that the client would choose to do
things.

i guess the downside is that if you really do have a method that takes
data and in and returns data (not an error indication), you've got 4
messages rather than 2.

[9fans] transpose

[rog]

i've done a version of the original 2nd edition transpose.

seems to work - only thing is i'm not sure about whether
i can post it as i derived it from the original source to
save time.

i can't remember if there was any relaxation of the old 2e
restrictions for fb/* stuff.