From: Kathy Yelick (yelick_at_EECS_dot_Berkeley_dot_EDU)
Date: Sat Feb 14 2009 - 06:57:12 PST
Tahar, There are multiple UPC implementations, so it's often the case that even if one does have a bug, another one will work. Here's a list of the compilers -- I hope someone will correct me if I've missed one: Berkeley UPC, bupc (upc.lbl.gov) Intrepid, gcc-upc (intrepid.com) HP UPC (h30097.www3.hp.com/upc) IBM UPC (http://www.alphaworks.ibm.com/tech/upccompiler) Cray UPC (www.cray.com) The first two are open source, so in principle the community at large can also fix bugs in them. Both also have active support teams and there are regular (at least annual) releases of both. The other three are closed source commercial products and also have regular releases and ongoing support. I think the quote you mentioned was only said once and later retracted. In particular, the Berkeley team does have people fixing bugs, so this kind of thing will be fixed, but as with most open source projects, not necessarily within a few days. This is true with vanilla gcc today, so you should not feel less comfortable about programming UPC than with C or C++. In both cases you can buy commercial compilers that come with higher level support guarantees or use open source ones in which problems get fixed, but not necessarily on a particular time scale. The Berkeley and Intrepid compilers are also highly portable and should run on any machine with shared memory (pthreads, as you're discussing) or distributed memory (using GASNet). Kathy ------------------------------------------------ Katherine Yelick NERSC Division Director Lawrence Berkeley National Laboratory One Cyclotron Rd., MS 50B-4230 Berkeley, CA 94720 Email: kayelick_at_lbl_dot_gov Phone: 510-495-2431 On Feb 14, 2009, at 4:58 AM, Tahar Amari wrote: > Hello Paul, > > Many thanks for this detailed reply. > > SInce I am new with UPC, it is not a criticism at all but simply > some thoughts before starting. > UPC seems certainlbut to be much easier to use than MPI. > > I worry a little bit about bugs, and so how reliable it would be to > put our projects to UPC. > I saw on the FAQs that there were some bugs and sometime some reply > like " thanks for this bug > , we do not have anybody working on this right now , but will > consider it the future". > > Is is the same for all implementation, IBM, HP ? > > Please understand again that I just want to enquire before making > the "big jump" because > I feel very interested by UPC, but do not want to face compiler > problems which I do not control, > when I hardly yet control the numerical or physical problems. > > Thank you very much for your impression, > > Tahar > > > > > URL : http://www.cpht.polytechnique.fr/cpht/amari > > Le 13 f�vr. 09 � 22:24, Paul H. Hargrove a �crit : > >> Tahar, >> I regret that nobody appears to have replied to your questions yet >> (or did not cc:ed the list if they did). >> The answer to your question is not a simple "Yes", but more a >> "probably". >> >> Out runtime can optionally use pthreads internally for implementing >> UPC threads within a single node, both with and without a network. >> So, there is no fundamental problem with linking the pthreads >> libraries. Additionally, I am aware of at least on project that >> uses pthreads in *addition* to UPC threads (as I suspect you are >> asking). In that case, each individual UPC thread retains its own >> identity and can spawn pthreads to execute C (or C++ or FORTRAN, I >> suppose) code, but the pthreads spawned by the user code cannot >> execute UPC code because they do not correspond to any MYTHREAD >> value. >> If you have more specific information about how you wish to mix >> pthreads with UPC, let us know and we might be able to clarify >> further. >> >> -Paul >> >> Tahar Amari wrote: >>> Hello, >>> >>> One of my code use Pthreads. >>> Is it possible to still use this piece of code with UPC ? >>> >>> Many thanks >>> >>> Tahar >> >> >> -- >> Paul H. Hargrove PHHargrove_at_lbl_dot_gov >> Future Technologies Group Tel: +1-510-495-2352 >> HPC Research Department Fax: +1-510-486-6900 >> Lawrence Berkeley National Laboratory >