Re: Policy proposal: Cpu extension code, update-ldsoconf
Greetings!
Michel LESPINASSE <walken@zoy.org> writes:
> 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).
>
Great!
> > 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:
>
Agreed.
> 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.
>
OK, I agree.
>
> 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.
>
Agreed that static libs using extensions should go here too. But I'm
not sure I understand the last sentence. Binaries won't go here,
right? (Its under /usr/lib, after all). So binaries using extensions
are either statically or dynamically linked to 'generic-equivalent'
code which probes the cpu at runtime and does the right thing (if in
a library, can be in /usr/lib), or dynamically linked to 'subarch
specific' code for which multiple versions can be installed at the
user's option -- truly generic in /usr/lib, SSE in /usr/lib/xmm, etc.
If this is so, then lets consider the use of the static 'subarch
specific' libs a package would provide in /usr/lib/.../. Anyone using
them to build a program couldn't include it in Debian, as it will have
hardcoded in a dependency on a particular cpu. Its still good to have
them for /usr/local and programs in $HOME, but packages should not
build-depend on these libs, to my understanding.
I do agree we ought to strive for the most optimal configuration
possible, but it may well be that a system which sacrifices 5% with
-fpic saves much more than that in lowered memory usage, robustness in
multi-user situations, and stability in terms of centralizing critical
code segments and maximizing code reuse. In general, this shared
vs. static issue is tradeoff different users will doubtlessly resolve
differently. The question is what to do in a distribution such as
Debian. It is already the policy to provide static as well as shared
libs for development, which is definitely a good idea. But we'd all
probably agree that to distribute both statically and dynamically
linked binaries would be bloat.
I guess we need to make a call, either as a distribution, or on a per
package basis, whether the majority of users would benefit from either
shared or dynamic binaries. I don't know if this has been
methodically sorted out or not, but virtually every program in Debian
is dynamically linked to something, and that seems a reasonable
choice. Atlas, which is extremely performance driven, may take a
small hit from fpic (haven't noticed anything significant), but the
real system performance gain comes when it is used as a run-time drop
in replacement for blas, transparently speeding up all programs which
dynamically link to blas. Imagine recompiling all that code!
So we can phrase this however you'd like, I'd just prefer not to imply
a preference against -fpic. It seems that from a distribution point
of view, shared libs are probably the preferred choice, but we should
ensure that the power user who wants the extra 5% can recompile
statically.
> > 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.
>
Great!
> > 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.
>
Wonderful. So how should we proceed from here?
> > 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.
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: