Ali Bahrami wrote: > Daniel Templeton wrote: > <snip> > >> 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). >> > > This sounds like a pretty good match for hardware capabilities. > You can produce multiple versions of your libraries, each tagged with > their specific hardware requirements, and then produce a shared > object filter on top of them. The runtime linker will select the > best library to actually load at runtime, based on your end user's > hardware. > > Here's a blog that Rod wrote about the subject of object filters: > > http://blogs.sun.com/rie/entry/shared_object_filters > > and the Solaris Linker and Libraries guide has some information > on the subject also: > > http://docs.sun.com/app/docs/doc/817-1984 > > This will work, as long as the options you want to use > correspond to the defined hardware capability bits. >
This is the right way to proceed if you can avoid generating libraries tuned for cache sizes, pipeline peculiarities, etc. If you must do the latter, you'll need to invent your own mechanisms, but keep in mind that new CPUs are added all the time so any CPU-specific tunings have a very limited shelf-life. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
