On Mon, Jun 25, 2001 at 03:16:27PM -0400, Camm Maguire wrote:
> Greetings! This is hardly formal, but it seems as though we don't
> have a policy on this yet, and a number of packages are appearing
> (e.g. atlas, gmp2) which can benefit enormously through the use of cpu
> extension instructions, such as {SSE,3DNow{{1,2}.
I have a few comments about this, I've been interested in this
question since I maintain the mpeg2dec package (not a debian package
yet though).
> 1) All code which will not run on all machines of its general
> architecture should be separated into a shared library.
This is much much much better than providing separate packages with
the same program optimized for different architectures IMHO.
However I think if someone wants to have code in his executable that
will detect the available CPU extensions and transparently choose the
right optimized routine to execute, I think this should be fine
too. So I'd suggest to rewrite the proposed policy to allow that.
proposal:
1) All user-visible programs placed in /bin or /usr/bin should execute
identically on all machines of a given architecture, independantly of
available CPU instruction set extensions. One of the accepted ways to
achieve this is to separate code into extension-dependant shared
libraries, subject to the conditions of this section of the policy.
Also one problem with shared libraries is the use of the -fPIC
option. On x86 this has a non-negligible cost, for libmpeg2 it was
somewhere between 5% and 10%. This kind of defeats the purpose of
providing optimized implementations in the first place :) See my
proposal below about that.
> 2) This library should be placed in a designated subdir of /usr/lib
> specialized for code requiring the cpu extension in question. All
> such directories should be agreed on and sanctioned by the policy
> committee. As a suggestion, the directory might be named after
> the cpu capability (as reported in /proc/cpuinfo) required to run
> the code, e.g. /usr/lib/xmm, /usr/lib/3dnowext, etc.)
looks like a good idea, but I'd like to add something to this paragraph:
Libraries placed in these directories are exempted from the obligation
to use the -fPIC compilation flag. The rationale is that this code has
been separated only as an easy way to comply with 1), not because we
actually expect to share this code with any other executables. Because
this code is time-critical, it makes more sense to avoid the runtime
cost associated with -fPIC here.
> 3) All functionality provided by this code should also be provided by
> a binary-equivalent generic shared lib of the same name and soname
> in /usr/lib.
definitely a good idea. we want a given package to run on the whole
architecture even when no extensions are available.
> 4) Ideally, ldso should be smart enough to search the special
> directories first given the running cpu characteristics. Barring
> this, a system script, update-ldsoconf, should be created, which
> packages can call at install/remove time, to add/remove the
> specialized paths appropriate to the running cpu to /etc/ld.so.conf
> ahead of /usr/lib and then run ldconfig. Optionally (and
> preferably), this script could also be run at boot time to catch
> cpu-upgrades and/or kernel upgrades (SSE requires kernel support).
> The path need not be added, and can be removed, if no libs exist in
> the directory.
looks good.
> Comments most welcome, but please cc me directly, as I'm not
> subscribed to some of these lists.
I do read the lists most usualy, but I appreciate to be cc:ed too.
Hope this helps,
--
Michel "Walken" LESPINASSE
Of course I think I'm right. If I thought I was wrong, I'd change my mind.
