Hi; That works well for pre-installed libraries and is something that should definitely be supported. However, you also have to support the case where someone provides an executable that has been compiled with either an Intel or an AMD-oriented compiler. In that case the library reference won't be applicable. Marvin. -----Original Message----- From: Michel Drescher [mailto:Michel.Drescher@uk.fujitsu.com] Sent: Thursday, June 08, 2006 6:02 AM To: Donal K. Fellows Cc: Marvin Theimer; Peter Lane; ogsa-bes-wg@ggf.org; Ed Lassettre Subject: Re: [ogsa-bes-wg] Questions and potential changes to BES, as seen from HPC Profile point-of-view Hi Donal, Marvin, all, Donal K. Fellows wrote:
Marvin Theimer wrote:
I suspect you'll see more specification of binary executable as time goes on. As people purchase multiple clusters with somewhat different hardware and as they add new hardware to existing clusters they end up with heterogeneous environments where the exact choice of hardware really does matter. For example, running numerical libraries that have been optimized for Intel or AMD on the opposite chip type can yield substantial performance penalties.
The right thing to do is to specify that you need the library using some kind of abstract name for it, and leave it to the BES container to figure out how to do that efficiently on the hardware allocated.
this is already included in the BES specification as a non-formal JSDL 1.0 extension. It has been incorporated from the ESI proposal, as a "esi:Library" element (the namespace probably needs adjustment). See also BES spec v1.3, page 16 (ch. 6.1.5 JSDL 1.0 Extensions) Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834