At Thu, 27 Jan 2005 18:09:49 +0100,
Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
BTW: I wonder why hwcap decisions are not cached in the ld.so.cache?
Why don't you check /etc/ld.so.cache? Hint:
strings /etc/ld.so.cache | grep /lib/tls on i686.
I know it places the
In article [EMAIL PROTECTED] you wrote:
BTW: I wonder why hwcap decisions are not cached in the ld.so.cache?
Why don't you check /etc/ld.so.cache? Hint:
strings /etc/ld.so.cache | grep /lib/tls on i686.
I know it places the libs in the cache, but it is still doing all the
stats, why?
At Sun, 23 Jan 2005 18:38:59 +0100,
Bernd Eckenfels wrote:
On Mon, Jan 24, 2005 at 01:16:12AM +0900, Junichi Uekawa wrote:
Looking at the rate of hardware changes, we will ideally be wanting
to add a new hwcap entry just about every year;
which results roughly in x10 time penalty every 3
On Mon, Jan 24, 2005 at 01:16:12AM +0900, Junichi Uekawa wrote:
The main problem with adding hwcap is that the number of directory
to be traversed doubles with every addition, which is an
exponential thing; rather than something linear.
Yes, this is a problem. But isn't it possible to change
On Mon, Jan 24, 2005 at 09:31:30AM +0100, Bastian Blank wrote:
I currently have problems with the implementation anyway, I can't
disable tls which makes problems on Xen, nor can I disable the usage of
optimized versions for testing of the other versions.
a quick workaround is to export
On Wed, Jan 19, 2005 at 09:43:18AM +0100, Bernd Eckenfels wrote:
I agree with you, but dont forget that this micro benchmark does not
really measure the overall effect on the system (i.e. to other
programs, to the number of meta data updates, cach useage) and it
does not take into account
On Wed, Jan 19, 2005 at 01:20:56PM +0900, GOTO Masanori wrote:
Ugh... that pushes the burden of maitaining support for new
architectures to the package.
Yeah - I think it's trade off - whether we support library
optimization package or we don't get a bit performance
On Tue, Jan 18, 2005 at 10:09:03PM -0600, Marcelo E. Magallon wrote:
What that means is that you need to make about 2000 stat(2) calls to
get _anywhere_ near what's measurable by a human and about 2 to
start getting said human annoyed.
I agree with you, but dont forget that this micro
At Sun, 16 Jan 2005 20:55:28 +0100,
Falk Hueffner wrote:
Marcelo E. Magallon writes:
On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote:
occurs when you have for example an ev56 library in lib/ev56, and a
ev67 CPU. Then the loader looks in lib/ev67 and then falls back to
At Thu, 13 Jan 2005 09:05:43 +0100,
Falk Hueffner wrote:
If other libraries
like mesa and libssl want to use /usr/lib/ev67 and so on, we may
consider to add HWCAP_IMPORTANT.
This should not be needed, since the library loader also looks in a directory
corresponding to the architecture
On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote:
occurs when you have for example an ev56 library in lib/ev56, and a
ev67 CPU. Then the loader looks in lib/ev67 and then falls back to
lib. Since glibc is very carefully undocumented in this area [1], I
didn't want to try
GOTO Masanori [EMAIL PROTECTED] wrote:
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
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.
There's a patch for this, which works fine, but wasn't
12 matches
Mail list logo
