Prev: Cannot mex with gfortran on Snow Leopard (64bit)
Next: fortran sensibility at specification order
From: nmm1 on 20 Oct 2009 04:27
In article <hbjqva$4iq$1(a)naig.caltech.edu>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
>Personally, I would rather use a language designed for parallel
>programming when I needed to do parallel programming. The structure
>of the programs is somewhat different. Now, one might design such
>a language with the look and feel of Fortran.

I agree but, unfortunately, I can't see how to get there starting
with Fortran as it is today.

>I would suggest anyone interested in such look at ZPL. For some
>reason ZPL looks to me a little like Pascal, and that does seem
>strange, but it is fundamentally designed as a parallel language.

Thanks. I will.

>> In particular, note that a general, conforming, correct Fortran
>> coarray program written to use multiple images will compile on a
>> serial system, but will not necessarily work. I.e. even in the
>> best implementations, it may well livelock, and the standard
>> quite rightly leaves that unspecified. So programmers HAVE to
>> know which variant they are using.
>
>Well, that doesn't sound right. So even on a parallel machine
>with N=1 it will fail?

Yes.

The simplest example is two images that handshake using atomic
variables, and wait for changes using spin loops. If the scheduler
doesn't suspend the active image until it waits for an event
(a very reasonable design), the program will simply loop in the
first image to start spinning on an unset variable.

Another one, which actually occurs in one of my programs, will
livelock even in programs with round-robin, preemptive schedulers.
I have some code to synchronise local clocks (for MPI, but it is
generic), which does the classic double handshake and repeats
until the round-trip time is small enough for use.

And so on ....


Regards,
Nick Maclaren.
From: Dan Nagle on 20 Oct 2009 05:53
Hello,

On 2009-10-20 04:04:58 -0400, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said:

> I wonder if it isn't that they are loud, but not so numerous.
> That seems to occur often in political discussions.

Actually, a good many coarray applications exist among those
who do not discuss their work at all.

> I would suggest anyone interested in such look at ZPL. For some
> reason ZPL looks to me a little like Pascal, and that does seem
> strange, but it is fundamentally designed as a parallel language.

ZPL is based on Modula-2, so it ought to look like Pascal.

How would you use ZPL on an irregular mesh?

While ZPL has some interesting ideas, it's of too limited
a range of applicability to gain my vote for a general-purpose
programming language.

I note that at the recent PGAS conference, UPC, CAF, Chapel and X-10
were all represented. ZPL was not.

--
Cheers!

Dan Nagle

From: Craig Powers on 20 Oct 2009 16:04
David Muxworthy wrote:
> The main point to me is the role of the standard. I think we'll have
> to agree to differ on whether it should aim be the dependable basis
> for producing portable programs worldwide, as it describes itself, or
> if it is now primarily a means of promoting new language features.

The problem, I think, is that sometimes in order to be the former, it
must also do the latter. If new features will inevitably arise to
address a particular needed capability, then the producers of the
standard can find themselves in a bit of a bind. On the one hand, they
can wait for one or more implementers to innovate, observe what does and
doesn't work, and attempt to standardize from there (with the
consequence that multiple incompatible, nonstandard alternatives are
likely to exist in perpetuity for backward compatibility reasons). Or,
on the other hand, they can attempt to get out in front, avoid
collisions between incompatible pre-standard alternatives, and in the
process become the ones doing the innovation in language features.

I don't pretend to know what's right here.
From: glen herrmannsfeldt on 20 Oct 2009 16:29
Craig Powers <craig.powers(a)invalid.invalid> wrote:
> David Muxworthy wrote:
>> The main point to me is the role of the standard. I think we'll have
>> to agree to differ on whether it should aim be the dependable basis
>> for producing portable programs worldwide, as it describes itself, or
>> if it is now primarily a means of promoting new language features.

> The problem, I think, is that sometimes in order to be the former, it
> must also do the latter. If new features will inevitably arise to
> address a particular needed capability, then the producers of the
> standard can find themselves in a bit of a bind. On the one hand, they
> can wait for one or more implementers to innovate, observe what does and
> doesn't work, and attempt to standardize from there (with the
> consequence that multiple incompatible, nonstandard alternatives are
> likely to exist in perpetuity for backward compatibility reasons).

It seems that it is some of each. Many features added to the standard
were previously extensions. As the were used more and more, people
got used to how they worked and asked for them. The standard version
is sometimes a little different, but maybe such that it isn't so hard
to change. I would say that was mostly true for F77, and somewhat
for F95.

> Or, on the other hand, they can attempt to get out in front, avoid
> collisions between incompatible pre-standard alternatives, and in the
> process become the ones doing the innovation in language features.

It seems that there were a variety of non-standard implementations
for dynamic allocation, such as Cray pointers. Doing dynamic
allocation right required many changes, and in that case coming
out with a new, self consistent form, possibly incompatible with
previous extenstions, seems like a better choice.

> I don't pretend to know what's right here.

-- glen
From: dpb on 20 Oct 2009 16:42
Craig Powers wrote:
....
> I don't pretend to know what's right here.

It seems to me there is no "right" that is provably so; that's what
makes it so difficult a question.

--
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Cannot mex with gfortran on Snow Leopard (64bit)
Next: fortran sensibility at specification order