Re: RFC: Merge the GUPC branch into the GCC 6.0 trunk

[Gary Funck <gary at intrepid dot com>]

On 12/01/15 12:19:48, Bernd Schmidt wrote:
> On 12/01/2015 06:31 AM, Gary Funck wrote:
> >At this time, we would like to re-submit the UPC patches for comment
> >with the goal of introducing these changes into GCC 6.0.
> 
> This has missed stage 1 by a few weeks, we'd have to make an exception to
> include it at this late stage.

Based upon the feedback, it looks like GCC 6.0 is not feasible.

> 
> >@@ -857,9 +875,14 @@ struct GTY(()) tree_base {
> >        unsigned user_align : 1;
> >        unsigned nameless_flag : 1;
> >        unsigned atomic_flag : 1;
> >-      unsigned spare0 : 3;
> >-
> >-      unsigned spare1 : 8;
> >+      unsigned shared_flag : 1;
> >+      unsigned strict_flag : 1;
> >+      unsigned relaxed_flag : 1;
> >+
> >+      unsigned threads_factor_flag : 1;
> >+      unsigned block_factor_0 : 1;
> >+      unsigned block_factor_x : 1;
> >+      unsigned spare1 : 5;
> 
> That's a lot of bits used up at once.

I provided some additional background in my reply to Richard.
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00136.html

> Does this solve anything that cannot be done with OpenMP, which we already
> support?

UPC's target use is similar to that of Co-Array Fortran (CAF),
mainly multi-node computations in addition to multi-core.
Also, in the sense that UPC makes syntactic extensions
it is arguably easier to write and to understand UPC programs
than the pragma based approach used by OpenMP and Cilk, or
library based solutions like MPI.

Here is an example application, parallel merge sort,
written in MPI, OpenMP, UPC, hybrid MPI/OpenMP, 
and hybrid UPC/OpenMP which illustrates how they
compare in terms of expressivity.  In general, the
bulks synchronous UPC implementation out-performs
the others.

https://github.com/gary-funck/parallel-merge-sort

> Can you show us any users of this that demonstrate that this is
> actually in use by anyone outside the universities responsible for UPC?

It is primarily used in universities and research labs.
Cray, IBM, and HP offer their own commercial compilers on
their HPC platforms.  Berkeley has an open UPC-to-C translator
and we have separately built a Clang-based compiler and
source-to-source translator.

> The language standard is apparently from 2005 [...]

The spec was updated in 2013.
http://upc.lbl.gov/publications/upc-spec-1.3.pdf

> but I've never heard of it and
> googling "upc" does not give any sensible results. The gccupc mailing list
> seems to have been dead for years judging by the archives. I'm worried we'll
> end up carrying something around as a burden that is of no practical use
> (considering we already support the more widespread OpenMP).

UPC is more similar to Co-Array Fortran (CAF) than OpenMP.
I don't keep up with developments in the OpenMP or OpenACC standards,
so am unaware of proposals to generalize them for multi-node
HPC applications.  As mentioned, IMO, UPC is more expressive
than OpenMP (which is pragma based).  Their programming
models are also different.  UPC is SIMD, and OpenMP uses
dynamic task dispatching.

Regarding a possible "burden", we have tried to modularize
the changes to minimize impact on the compiler.

We floated the idea of including UPC in GCC a few years back;
there were no objections at that time.  In the mean time,
we have been implementing changes based upon feedback,
porting the runtime to other communication layers
and implementing the changes needed to conform
to the 2013 UPC specification.

thanks,
- Gary