(j3.2006) [Fwd: Fortran 2008 query]
Van Snyder
Van.Snyder
Thu Oct 26 20:29:35 EDT 2017
On Thu, 2017-10-26 at 22:14 +0000, Bill Long wrote:
> Not sure what you mean. With the initialized data in the executable
> file, that file becomes larger. For just 4000 numbers, that extra
> size is not significant. But other examples might be really big. How
> the executable file is copied to all the processors is beyond the
> compiler. That?s the job of the program launching software, which, one
> would hope uses some sort of fan-out tree to reduce network load.
>
> On the other hand, the compiler could generate the executable file
> without the constants and then include reading the values and
> distributing them as part of the code that is executed before the main
> program starts. Basically automatically doing what programmers do by
> hand now. On the other hand, the programmer can normally be more
> optimal, especially if the values are not needed right away. In that
> case the read by image 1 can be asynchronous and the co_broadcast call
> can be put off until the values are actually needed. All sorts of
> pretty normal optimization tricks are available to the experienced
> programmer.
So let the programmer decide instead of dictating your private
programming style by way of pointless restrictions in the standard. Put
your recommendations in your software development group's style guide,
not the standard.
>
>
> Cheers,
> Bill
>
>
> > On Oct 26, 2017, at 3:32 PM, Keith Bierman <khbkhb at gmail.com> wrote:
> >
> > I dunno, if you have all the constants in at compile time the compiler might be able to leverage a multi-cast facility rather than N reads from a billion nodes....
> >
> > Keith Bierman
> > khbkhb at gmail.com
> > 303 997 2749
> >
> > On Thu, Oct 26, 2017 at 2:27 PM, Bill Long <longb at cray.com> wrote:
> >
> > > On Oct 26, 2017, at 2:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > >
> > >>
> > >> We could say that it is a processor-dependent value greater or equal to 1023.
> > >
> > > Ridiculously small. Why design a language for machines that were obsolete twenty years ago? We should be designing for the future, not the past.
> >
> > You mean the real future where the amount of memory/core continues to decline, and where broadcasting the executable out to all the participating processors becomes slower as the size of the executable increases (because of initialized arrays)? The better option in cases like this is usually to read the data in from an unformatted file when the program starts. Maybe just to image 1 and broadcast it from there.
> >
> > Cheers,
> > Bill
> >
> >
> > Bill Long longb at cray.com
> > Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> > Bioinformatics Software Development fax: 651-605-9143
> > Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> Bill Long longb at cray.com
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20171026/b799b140/attachment.html>
More information about the J3
mailing list