Re: hwcap supporting architectures?
At Tue, 11 Jan 2005 19:03:44 -0600,
Marcelo E. Magallon <email@example.com> wrote:
> > Note that MMX will be removed from the next glibc 2.3.4 upload. It
> > will provide only SSE2 (and CMOV, debian-specific for only VIA C3
> > processor).
> Well, there's hand-crafted MMX code, so it's runtime checked. I guess
> that would take care of it. After following the advice in other
> replies, gcc is generating CMOVs, too.
If your "runtime check" means "hand-crafted MMX code checks the
hardware MMX availability and it automatically judges to use MMX
instruction on execution time", you don't need to care about
library file location.
However, if you specify any architecture optimization code like
-march=i686, you need to put such library on special HWCAP directory
> > > My understanding is that this is also significant on sparc
> > > (-mcpu=v9) and that this belongs in /usr/lib/v9. Is this right?
> > Sparc defines HWCAP_SPARC_V9 and HWCAP_SPARC_ULTRA3. So v9 is right.
> > See glibc sparc packages.
> Where would ultra3 libs go? /usr/lib/sparc/ultra3? (sorry about the
> naive question, but I had a hardtime finding this sort of
I think /usr/lib/ultra3 is the right directory if you specify ultra3
optimization option to gcc. Note that unfortunatelly I don't have
access to any ev67 or ultra3 machine - so I don't test it.
> > > Mesa upstream uses -mcpu=ev5 -mieee on alpha. Is that ok? Where
> > > does this belong into? /usr/lib/ev5?
> > IIRC, alpha does not define any hwcaps.
> Oh... I was looking at the atlas packages (I *think*), and it installed
> some libs in /usr/lib/ev5 (or something along those lines). Is that
> manually handled by atlas or something like that?
Please read README.Debian.gz - atlas2-ev5 package says user needs to
use LD_LIBRARY_PATH or to add /usr/lib/ev5 directory into
/etc/ld.so.conf. This is another way to use hardware optimization
library. However a big drawback is user needs to add such directory
under his/her responsibility (if hardware is downgraded from ev56,
user needs to edit the configuration again because atlas may start to
barf illegal instruction).
BTW, I would like to warn about compiler option tuning optimization.
I think in most case the hardware specific optimization code does not
accelarate uesr application so much (except for HPC apps). 3% speed
up is sometimes hard issue for processor architect/creator, but I
think it's not large improvement - if your application issues disk IO
frequently, the performance is hidden by disk seek slowness. Pure HPC
applications pay a lot of efforts of decreasing IO/communication,
loop, unrolling and data structure design. Application code
optimization makes a lot of performance improvement compared with the
lazyness compile option tuning (but some compiler like intel on ia64
is out of scope, though). So, using HWCAP library is not everytime
good choise. IIRC, an article said optimization comparison on Gentoo
showed no speed gain.