Home > Archive > Fortran > February 2008 > Re: Will Co-Array Fortran be considered a valuable tool for next-generation programmi
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Will Co-Array Fortran be considered a valuable tool for next-generation programmi
|
|
| Michael Metcalf 2008-02-22, 8:12 am |
|
"Tim Stitt" <Timothy.Stitt@gmail.com> wrote in message
news:bd6a7a89-53c0-4c57-8344-887336b12b4b@o77g2000hsf.googlegroups.com...
> Hi all,
>
> Can anyone suggest an up-to-date tutorial on
> Co-Array Fortran and/or publicly available compiler implementations.
>
See ftp://ftp.nag.co.uk/sc22wg5/N1651-N1700/N1669.pdf for a fairly
up-to-date explanation. It is based on experience with the Cray
implementation of them. I understand that a simplified version will be part
of the next standard, Fortran 2008.
Regards,
Mike Metcalf
| |
|
|
"Michael Metcalf" <michaelmetcalf@compuserve.com> wrote in message
news:tkzvj.34024$s33.25031@trndny06...
/or publicly available compiler implementations.
> See ftp://ftp.nag.co.uk/sc22wg5/N1651-N1700/N1669.pdf for a fairly
> up-to-date explanation. It is based on experience with the Cray
> implementation of them. I understand that a simplified version will be
part
> of the next standard, Fortran 2008.
In response to the subject, no one programming language is "forever". There
were so many parallel programing languages, developed and introduced, and
disappeared. nCube (hypercube), encore, sequent, alliant, cray, ibm ,
thinking machine,, .... There were lots of parallel programming languages.
In my personal opinion, programming language is not an issue. What we need
is good parallelism (efficient parallel algorithm). Parallel computing is
not to parallelize do-loops. If there is a good parallelism, no matter in
what kind of programming language, it works efficiently. A good parallelism
can be programmed in message-passing machine and memory-sharing machine. In
my opinion, developing parallel algorithms is more important than learning
programming languages.
Making "co-array" as a fortran standard??? Is it really necessary? Or, let
programmer make his own choice? I just take look at the "the above PDF"
introducing co-array. In my opinion, it may be not the best to use co-array
on memory-sharing machine. For example, the PDF file writes "If an image
executes the statement:
x(:) = y(:)[q]
the co-array y on image q is copied into co-array x on the executing image".
Since it is on memory-sharing machine, why to waste system resource to
duplicate every co-array? Co-array may make sense on message-passing machine
or NUMA.
| |
| Dan Nagle 2008-02-22, 10:27 pm |
| Hello,
On 2008-02-22 15:57:36 -0500, "post" <no-spam@equation.com> said:
>
> Making "co-array" as a fortran standard??? Is it really necessary? Or, let
> programmer make his own choice?
The problem with the "let popularity decide" view is the very high cost,
to both the compiler vendor and the application programmer, of parallel
programming. Applications programmers don't want to invest years
to use a paradigm that isn't well-supported. And compiler vendors
don't want to develop features if they won't help sell compilers.
So everyone waits for the other guy to move first,
and the language goes nowhere.
Parallel hardware is here today, and coarrays are known
to work well on DMP, SMP, and everything in between.
The Fortran standard says what appearances are preserved,
not how to make it happen.
--
Cheers!
Dan Nagle
| |
| Janne Blomqvist 2008-02-23, 8:11 am |
| On 2008-02-22, post <no-spam@equation.com> wrote:
> In response to the subject, no one programming language is "forever".
That remains to be seen. FORTRAN was the first, and is still
around. Of course, "modern" Fortran style looks quite different from
that 50 years ago. As someone said, "languages evolve or they die".
> In my personal opinion, programming language is not an issue. What we need
> is good parallelism (efficient parallel algorithm). Parallel computing is
> not to parallelize do-loops. If there is a good parallelism, no matter in
> what kind of programming language, it works efficiently. A good parallelism
> can be programmed in message-passing machine and memory-sharing machine. In
> my opinion, developing parallel algorithms is more important than learning
> programming languages.
This looks like the parallel equivalent of the "why do we need
high-level languages when everything can be done in ASM?"
argument. Obviously, a parallel language can't magically turn a serial
algorithm into a parallel one. But hopefully a parallel language can
make parallel algorithms easier and less error-prone to implement.
> Or, let
> programmer make his own choice?
I don't see why coarrays would prevent a programmer from using MPI,
OpenMP, pthreads or whatever he likes.
> I just take look at the "the above PDF"
> introducing co-array. In my opinion, it may be not the best to use co-array
> on memory-sharing machine. For example, the PDF file writes "If an image
> executes the statement:
> x(:) = y(:)[q]
> the co-array y on image q is copied into co-array x on the executing image".
> Since it is on memory-sharing machine, why to waste system resource to
> duplicate every co-array? Co-array may make sense on message-passing machine
> or NUMA.
If one is writing for a SMP machine I suppose it can make sense to use
co-arrays directly in expressions rather than first copying to local
arrays. Although even in that case copying might improve performance
due to avoiding cachelines ping-ponging between the processors. Of
course such a code will likely perform very badly on a message-passing
or NUMA machine.
Anyway, it seems that Intel is following AMD/IBM/(Sun?) in adding
memory controllers to each processor, so in a few years practically
all new multisocket machines will be NUMA. True UMA SMP will only be
found in low-end single socket multicore machines.
--
Janne Blomqvist
| |
|
|
"Janne Blomqvist" <foo@bar.invalid> wrote in message
news:slrnfrvtm3.rnf.foo@vipunen.hut.fi...
> That remains to be seen. FORTRAN was the first, and is still
> around. Of course, "modern" Fortran style looks quite different from
> that 50 years ago. As someone said, "languages evolve or they die".
>
What I said is there were so many parallel programming languages introduced
and disappeared "completely", not "disappeared or died" partially.
>
> This looks like the parallel equivalent of the "why do we need
> high-level languages when everything can be done in ASM?"
> argument. Obviously, a parallel language can't magically turn a serial
> algorithm into a parallel one. But hopefully a parallel language can
> make parallel algorithms easier and less error-prone to implement.
>
You missed my point. I never said we do not need high-level language for
parallel computing. My question is whether it is necessary to put parallel
programming language, i.e., co-array, as a fortran standard. Not every
fortran programmer works on parallel computing. If it is a standard, every
fortran programmer needs to learn parallel computing. Do we need to put
others, e.g., openGL, as a fortran standard?
>
> I don't see why coarrays would prevent a programmer from using MPI,
> OpenMP, pthreads or whatever he likes.
>
It is based on your personal opinion. Concept of co-array is not new.
Co-array is similar to, for example, "sched", that was introduced about 20
years ago. Sched run multiple copies ("processes"), co-array also run
multiple copies ("images"). In sched, shared variables are declared in
common area (by statement common). In co-array, it is necessary to copy
shared variables from one image to another image. Possibly, no one uses
sched presently. If your personal opinion can be held, the same question to
you "why sched would prevent a programmer from using OpenMP, pthreads or
....."
If we were on memory-sharing machine, all shared variables can be accessed
by cooperative tasks. Why to waste system resource to duplicate every
co-array? One concern is "cache coherence". A good parallelism can avoid
"false cache". It is not absolutely necessary to waste system resource to
duplicate co-array to gain efficiency.
>
> Anyway, it seems that Intel is following AMD/IBM/(Sun?) in adding
> memory controllers to each processor, so in a few years practically
> all new multisocket machines will be NUMA. True UMA SMP will only be
> found in low-end single socket multicore machines.
>
When nccNUMA (deemed as memory-sharing) available, "cluster" may be the next
one to disappear.
|
|
|
|
|