From: Tahar Amari (amari_at_cpht.polytechnique.fr)
Date: Sat Feb 14 2009 - 08:16:37 PST
Kathy, Thanks a lot, this is very helpful and makes me feel much more comfortable. Tahar -------------------------------------------- T. Amari Centre de Physique Theorique Ecole Polytechnique 91128 Palaiseau Cedex France tel : 33 1 69 33 42 52 fax: 33 1 69 33 30 08 email: <mailto:[email protected]> URL : http://www.cpht.polytechnique.fr/cpht/amari Le 14 f�vr. 09 � 15:57, Kathy Yelick a �crit : > 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 >>