(j3.2006) (SC22WG5.5561) LCPC conference in Raleigh

[Van Snyder]

I attended the 28th Languages and Compilers for Parallel Computing (LCPC
2015) conference http://www.csc2.ncsu.edu/workshops/lcpc2015/ in Raleigh
last week.  This wasn't funded by JPL; a friend who is the chair of the
Computer Science department at NCSU paid my way.

I stood beside Damian's poster about OpenCoarrays, and gave a 2-minute
presentation about it.

There were several interesting talks.  Several times I mentioned that
what presenters were describing as rather heroic efforts are automatic
in coarray Fortran.

Several people asked "Why coarrays?"  I pointed to one line of code,
something like X = Y[7] on Damian's poster, and asked them to compare it
to the page of MPI code on the next poster.

That next poster was presented by Hadia Ahmed <hadia at cis.uab.edu>,
concerning work she had done with Anthony Skjellum and Peter Pirkelbauer
at the University of Alabama at Birmingham.  They used ROSE to analyze
legacy C+MPI code having blocking transfers, and transformed it to use
non-blocking transfers.  Their analysis might be useful in Fortran
compilers to decide when coarray transfers can be non-blocking, and to
report what users have done wrong that prevents that.  This project is
called PETAL.  There should be something in the LCPC 2015 proceedings
when they appear online.  There's a poster about the parent project,
called iProgress, from a different (IPDPS) meeting last year, at
http://iprogress.cis.uab.edu/media/2014/05/ipdps_poster_final.pdf.

I don't know ROSE http://rosecompiler.org well, but another attendee
mentioned that it can parse C, C++, UPC, Fortran 2003, Java, Python and
PHP, and that it represents them using a common abstract syntax tree.
It can also un-parse (pretty print).  If ROSE were extended to
understand coarrays (I sent them a message to urge them to do it), the
work that Hadia did might be useful to transform Fortran+MPI to coarray
Fortran.  If ROSE can unparse to a different language from its input, it
could conceivably convert C+MPI code to coarray Fortran.

Many presentations described unstructured problems, such as arbitrary
mesh representations in Earth science or fluid dynamics calculations.
Paul Kelly <p.kelly at imperial.ac.uk> from Imperial College London
described work he had done in this area.  He developed what he calls an
inspector-executor framework, which looks hard at a problem to develop
efficient schedules to solve it.  This is effective if one's code
examines the same mesh many times.  His tool is embedded in Python.  It
generates and compiles C code at runtime.  The performance frequently
exceeds hand-coded C.  Other speakers described graph problems (which
are isomorphic to sparse matrix problems).  These sorts of problems
don't lend themselves well to parallelization using coarrays, array
operations, FORALL statements, or DO CONCURRENT constructs because the
parallelization opportunities arise from the data, not the program
structure.  It would be useful to contemplate more parallelism
constructs in Fortran to address them.  Many speakers remarked that
multigrain parallelism gives greater speed-up.  Some speakers mentioned
fork-join constructs.  Others mentioned tasks and threads (I don't know
what distinctions they drew between these).  Somebody mentioned futures.
Padma Raghavan <padma at psu.edu> from Penn State University mentioned maps
(I don't know what she had in mind, but she did invite me to contact her
offline; maybe she said map reduce).

Dhruva Chakrabarti <dhruva.chakrabarti at hpe.com> mentioned that effective
use of persistent store (he mentioned at least three technologies, but I
only remember memresistors and MRAM) provides challenges for programming
languages.  It might be fruitful to think about the relationship between
persistent store and Fortran.  One tiny step might be to support what
Multics called "associated memory" and POSIX calls a "memory-mapped
file" (which is already supported by Boost, Java, D, Ruby, Python,
Perl, .NET, PHP, R, J, and probably others).

One of the conference organizers, Chen Ding <cding at cs.rochester.edu> at
the University of Rochester http://www.cs.rochester.edu/~cding/, hoped I
would come to the meeting next year (in Rochester).  I see no prospect
to get funding to attend further meetings.  It would be useful if
somebody represented Fortran at these meetings (and also at PPoPP
meetings).

Van