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.

Re: [9fans] parallel programming in Plan 9

[boyd, rounin]

ron minnich wrote:
> For grid, David Abrahamson tells us that the users want a simple
> open/read/write/close interface for their apps.

yeah it should be done like a limbo chan,
but you'll need process migration.

Re: [9fans] parallel programming in Plan 9

[ron minnich]

For grid, David Abrahamson tells us that the users want a simple
open/read/write/close interface for their apps. They want to name and open
net connections with the same ease that they name and open files. They
want to substitute files for net connections for testing. They don't want
to have to use gridFTP or similar kludges for getting to files;  they want
the files to be accessible whereever they are. They have no particular
love of complex components and C++.

These user wants are of course in complete opposition to what CS people
want to provide for the grid. "I'm from the CS dept. and I'm here to
help".

When we looked at what the users wanted, as opposed to what the CS
researchers were planning to provide, we realized that Plan 9 fit the user
needs for Grid very well indeed, which is what got us started trying to
build the 9grid in the first place.

Don't assume that because MPI is ubiquotous that everyone wants it either.
They just assume that it's all they are going to get. Personally, I don't
exactly love MPI.

For on-machine cases, rfork with RFMEM will get you pretty far for
parallel programming. See the 'cpu' command for an example of using
shared-memory semaphores.

ron

Re: [9fans] parallel programming in Plan 9

[andrey mirtchovski]

> 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? 

There was an MPI implementation using Plan 9 cross-system mounts.
There were even talks of rewriting it as a proper file system.  The
paper was rejected because a) nobody cares about reliability; b)
everybody cares about squeezing the last 15µs out of their
implementation; c) plan9 won't be interesting as research for a while
more -- Linux is where it's at; d) the paper wasn't all that good.

I can tell you where it is, if you're really interested.

As for Plan 9 vs MPI -- as Presotto said, threads and lightweight
procs are perfect for handling load on a single machine (SMP
preferably -- you should see how two or more cpus "soak load", to use
Geoff's words, under Plan 9).  You wouldn't get a fast MPI
imlementation under Plan 9 unless you dig very deep into the OS, but
then you can't beat Plan 9 for exporting services and interfaces for
them (file servers) for others to use.

Currently restricted to Plan 9-based clients only :)

andrey

Re: [9fans] parallel programming in Plan 9

[Scott Schwartz]

| Are threads in libthread just a
| convenient representation of a particular type of process or they
| different beings altogether?

It provides uniform notation for dealing with lightweight processes
(kernel level entities) and coroutines (language-runtime entities).

Re: [9fans] parallel programming in Plan 9

[David Presotto]

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

The kernel doesn't support threads per se, there's only one process
type.  Processes may share memory.

Libthread is a user level library that allows multiple threads
per process, in addition to multiple processes.  It also
provides typed CSP like channels.

As a user of libthread, you can start a thread in the current process
	threadcreate()
or in a new process
	procreate()
Threads created in the same process use cooperative scheduling,
i.e, when one yields the processor (implicitly by calling one
of the channel functions or explicitly by calling rendezvous)
another can run.  However these threads are only logicly separate.
Since the kernel knows nothing about them, they can only run
sequentially on a single CPU.  If one calls a blocking system
call (read, sleep, etc) none of the others will run.

Therefore, a process that wants to make use of multiple processors
and/or that wants to allow some threads to block on system calls
will use proccreate (which in turn calls rfork) to create threads in
multipe processes.  You can mix and match; the threads look the same
as far as communication is concerned.

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

From: James Horey <jhorey@unm.edu>
To: 9fans@cse.psu.edu, schwartz@bio.cse.psu.edu
Subject: Re: [9fans] parallel programming in Plan 9
Date: Wed, 18 Feb 2004 15:36:14 -0700
Message-ID: <4033E8DE.1020501@unm.edu>

Scott Schwartz wrote:

>Russ wrote a nice little essay that addresses some of the language
>level ideas.  Maybe the 9grid folks will write a similar essay
>(if the inferno guys haven't already.)
>
>http://plan9.bell-labs.com/who/rsc/thread/index.html
>
>
>
I am a bit confused about libthread in Plan9; I recall reading that Plan
9 supports creating processes that share the same address space as the
parent process using rfork, but that Plan 9 doesn't really differentiate
between a thread and a process per se. Are threads in libthread just a
convenient representation of a particular type of process or they
different beings altogether?

-James Horey

Re: [9fans] parallel programming in Plan 9

[James Horey]

Scott Schwartz wrote:

>Russ wrote a nice little essay that addresses some of the language
>level ideas.  Maybe the 9grid folks will write a similar essay
>(if the inferno guys haven't already.)
>
>http://plan9.bell-labs.com/who/rsc/thread/index.html
>
>
>
I am a bit confused about libthread in Plan9; I recall reading that Plan
9 supports creating processes that share the same address space as the
parent process using rfork, but that Plan 9 doesn't really differentiate
between a thread and a process per se. Are threads in libthread just a
convenient representation of a particular type of process or they
different beings altogether?

-James Horey

Re: [9fans] parallel programming in Plan 9

[Scott Schwartz]

Russ wrote a nice little essay that addresses some of the language
level ideas.  Maybe the 9grid folks will write a similar essay
(if the inferno guys haven't already.)

http://plan9.bell-labs.com/who/rsc/thread/index.html

[9fans] parallel programming in Plan 9

[James Horey]

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