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 _______________________________________________ opensolaris-discuss mailing list [email protected]
