Please....
I work with distributed computing in the university environment
(Finishing off my masters thesis) and I see those discussions
every day.
I am working with message passing myself, and of course I find
that neat and interresting. And I have worked with shared memory
machines too, and that is allso nice.
Which is better or worse of message passing or shared memory is
a matter of religion: the professors usually beat eachother up
with arguments for which is of preference. As another source for
frequent arguments is if message passing should be synchronous
and asynchronous. If we want to discuss the pro/cons, then that's
fine, and I would be pleased to supply arguments for both to be
the better - or the worse. It is a fact, that both have
advantages under different conditions, and that they have
disadvantages aswell.
So let's stop being silly trying to convince eachother that
there is only one way to do it. (I remember Larry Wall has
"There is more than one way to do it" as the slogan for Perl)
However interresting the arguments might be is hardly an issue of
the kernel mailing list, so let's keep the focus here.
If we are to discuss the pro/cons of message passing and shared
memory, then I think we should:
1) decouple it from the kernel list
2) decouple it from DIPC, MPI and other current implementations,
and stick with the models behind.
just my $0.2
cheers
- --thomas
On 25-Jan-98 Trond Eivind Glomsrød wrote:
> Kamran <kamran@wallybox.cei.net> writes:
>
>> > . same programming model no mater what your
>> > environment
>>
>> I believe they have taken a worst case approach by adopting
>> a message
>> passing programming interface everywhere.
>
> That isn't "worst case". MPI is nice to work with...
>
>> > . ease of use
>>
>> You should be an old hand in message passing systems.
>> Message passing is not
>> what most people feel comfortable with.
>
> For distributed numerical computing - yes.
>
>> Global variables and stack variables are the means
>> of communication between different parts of ordinary
>> programs, and these are
>> shared memories. Using multiple threads or processes is just
>> a step away.
>> Message passing can only be easier for people who are used to
>> it.
>
> I've programmed pthreads. I've programmed MPI. MPI is simpler,
> easier
> and cleaner.
>
>> >: *) Programs using DIPC can be run in a single computer,
>> >: even on Linux
>> >: kernels without DIPC support! There is no need to
>> >: modify and compile
>> >: the sources to achieve this.
>> >
>> >Ditto for MPI.
>>
>> Can you run an MPI application without first installing MPI
>> ??
>
> You need it installed where you compile the app, but link with
> it
> staticaly (not much prob, since at least mpich builds
> statically by
> default anyway). You don't need something to run on any of the
> computers.
>
>> >: *) You don't have to learn some new programming
>> >: interfaces.
>> >
>> >Yes you do - you have to learn shared memory. Which is
>> >much, much harder for
>> >people to grasp then you might think.
>
> Agreed.
>
> Many parallell computers have supported this feature (Cray T3E
> and
> Intel Paragon springs to mind ;). It's not used. People
> _prefer_ using
> MPI - it's a clean interface for what you're doing.
>
> --
> Trond Eivind Glomsrød
> http://s9412a.steinan.ntnu.no/~teg/ ** teg@pvv.ntnu.no
- ---------------------------------------------------
E-Mail: Thomas Heide Clausen <voop@innocent.com>
URL: http://www.cs.auc.dk/~voop/
Masters student in the distributed systems group
Department for Computer Science, Aalborg University
Visitor at Open Systems Lab, University of Illinois
Urbana-Champaign
Date: 25-Jan-98, Time: 03:33:57
Unite for Java! - http://www.javalobby.org
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNMqnusQLb2bL5bWVAQGgQAP/clyT5LwUQ7REYZgDwiuAYdY9w/kOYqBF
RCGJZIJ/Wxqpkxx9N6pUrXwriK2AoptXeuXN8Hguz1A1zcrbsmB5TWlw0Ogggayz
+kK6iC4sxIQf4AmzxolvO/JaWGPRgtiuFFlEaUSsFDMoA1xs9HdLIdiboNB09D+G
6GbkpKgg4K8=
=DMLU
-----END PGP SIGNATURE-----