Re: hwcap supporting architectures?

[Junichi Uekawa <dancer@netfort.gr.jp>]

Hi,

>  Before asking here I went thru several mailing list archives.  What I
>  found was a general argument along the lines of "don't add _that_ hwcap
>  because that will increase the size of the list of paths that you have
>  to stat(2) in order to find the library and that's slow".  In
>  particular upstream doesn't seem to like the idea much.  I just can't
>  find the reason why they think the stat(2) call is _so_ expensive that
>  it will hurt system performance.  There was some mention of a glib
>  issue with plugins.  I couldn't find further data points on that...

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.

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 years.

> 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 20000 to
> start getting said human annoyed.

Which will be reachable within 10 or 20 years of time.

Thus, to be realistic, a linear or O(1) scheme, or some kind of 
library path caching scheme is required; time to do some coding?




Ref:

Having a hwcap of 'a' and 'b' and 'c' requires lookup of 

a/
a/b/
a/b/c
a/c/
b/
b/c
c/


Having a hwcap of 'a' and 'b' and 'c' and 'd' requires lookup of 

a/
a/b/
a/b/c
a/c/
b/
b/c
c/
a/d
a/b/d
a/b/c/d
a/c/d
b/d
b/c/d
c/d
d

regards,
	junichi