(j3.2006) (SC22WG5.3745) Nick's MPI non-blocking proposal

[Brian Smith]

I will likely try it tomorrow as it currentlys a pain to download stuff from 
my laptop to the RH Linux system.
For reasons that are beyond me, the router decided to change the address of 
the RH Linux system and now the
Laptop cannot see the Linux system.  I can see the Linux system from my 
other Dell deskside with its new address.
I can ssh/scp to UNM from the Laptop. So I suspect some firewall nonsense on 
the Laptop but I have tried everything
I can think of in terms of turning off Windows/bitdefender firewalls. I did 
reboot the router which appeared to allow the deskside Windows system to see 
the RH Linux machine, which it was doing before.  I hate computing.

----- Original Message ----- 
From: "Van Snyder" <Van.Snyder at jpl.nasa.gov>
To: "fortran standards email list for J3" <j3 at j3-fortran.org>
Sent: Thursday, December 04, 2008 5:09 PM
Subject: Re: (j3.2006) (SC22WG5.3745) Nick's MPI non-blocking proposal


>
> On Thu, 2008-12-04 at 15:14 -0800, Aleksandar Donev wrote:
>> Bill Long wrote:
>>
>> > Actually, I find it massively confusing.
>> No surprise, since you are confused about what Nick means by I/O.
>> Nick's proposal is meant to cover send/receive as well. It is I/O in
>> common computer science lingo, .... Just replace I/O with "data
>> transfer" and you should be less confused reading his draft.
>
> I haven't used MPI for 12 years, so there is much about it I don't
> remember, and I'm sure there are developments since I stopped using it.
> But...  My recollection was that it was an enormous kludge that does
> almost nothing other than I/O.  My present codes use PVM, but only for
> inter-program data transfer.
>
> Yeah, there's some synchronization stuff, too, but if you know you have
> to accomplish this using interprocess or interprogram communication, as
> opposed to inter-image shared-memory communication, you might as well do
> that with I/O, too.
>
> Therefore, Nick's proposal inevitably adds yet another kludge to the
> dung heap.
>
> Several times, it has been proposed to add one more spec to the OPEN
> statement to give extra processor-dependent information to the
> processor, with notes pleading to use the information to set up an
> interprocess communication channel, perhaps using MPI, PVM or some
> proprietary method.  I proposed this in 1986, 97-114:17.3 and 08-204,
> and others have proposed it, too.  08-204 proposed adding one row to a
> syntax rule, a dinky one-paragraph subclause in Clause 9, one item in
> Annex A, and one small paragraph in Annex C -- altogether 19 lines of
> plain text, and inevitably much less in typeset LaTeX.  Compare this to
> the 406 pages of MPI-3.
>
> If that were in place, perhaps with the addition of arrays of unit
> numbers in WRITE statements for broadcasts, and if asynchronous I/O and
> DIO worked with it (and why wouldn't they?), why would anybody use MPI
> or PVM for anything other than legacy codes?  If it had been done in
> Fortran 90, would anybody ever have used MPI or PVM in Fortran?
>
> -- 
> Van Snyder                    |  What fraction of Americans believe
> Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
> Any alleged opinions are my own and have not been approved or
> disapproved by JPL, CalTech, NASA, the President, or anybody else.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>