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