The typical solution to this type of problem is basically what you outlined as option 2, provide all versions and provide a method to choose. Only there is already a method in Solaris/OpenSolaris, namely the HWCAP linking option. This allows the runtime linker to choose among several equivalent libraries and find the best one of the alternatives. See the "Linker and Libraries Guide" on docs.sun.com for the details.
Daniel Templeton wrote: > I don't know if this is an PSARC question, a SFW gate question, or a > general OpenSolaris question, so I'm cross-posting all over the place. :) > > I'm a member of the Solaris HPC team, and we're working on porting a > series of HPC libraries and applications to OpenSolaris, mostly to the > SFW consolidation (for the libraries at least). The thing about HPC > libraries, though, is that they are extremely performance sensitive. > Compiling with -xarch=generic is a very bad thing, because it means that > users will see the (relatively) poor performance and take it as a > negative reflection on OpenSolaris. What we want to do is provide > highly optimized libraries so that users get the maximum performance > possible and see that OpenSolaris blows the doors off of Linux. The > problem is that if we tune these libraries (at compile time) to the > advanced chip sets that HPC customers tend to be running, the libraries > won't function on older chip sets, which is rather unkind to users not > running the latest chip sets. With SS11, the problem doesn't seem so > bad, but when the switch to SS12 happens, several more architectures > enter the picture. (As an aside, for the HPC libraries, it would be > *really* nice to be able to use SS12 to get the best performance > possible! Thoughts?) > > The question on the table is how we should go about providing optimized > libraries for all reasonable chip sets. Here are some possible solutions: > > 1) Offer each library as a series of packages, each tuned for a given > architecture, plus one generic version to cover all the bases. For > example, SUNWfftw (-xarch=generic), SUNWfftw-v9b, SUNWfftw-sse2, etc. > Users can then pull down the package for their particular architectures, > and the generic package fills in the blanks. A potential problem is > making sure the build machines can handle the specific architectures. > (Does cross-compiling have a performance impact?) > > 2) Offer a single package that includes all the tuned libraries under a > sub-directory and provide a way to switch among them, such as the > modules command (which is on our list of things to port). > > 3) Offer a single package that only includes libraries for the latest > chip sets and screw everybody else. > > A second question is whether it's OK to have an OpenSolaris open source > package depend on a Sun licensed package, such as Sun Studio Express for > the performance libraries (lapack and blas in particular). If not, > we're going to have issues with a lot of these HPC libraries. > > I would love to hear comments and suggestions. I BCC'ed the PSARC list > since it's Sun internal, so handle accordingly. > > Thanks! > Daniel -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
