why not a single PETSc library

[Matthew Knepley]

On Tue, Jun 9, 2009 at 7:40 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> On Tue, Jun 9, 2009 at 8:02 PM, Matthew Knepley<knepley at gmail.com> wrote:
> > On Tue, Jun 9, 2009 at 5:19 PM, Lisandro Dalcin <dalcinl at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 9, 2009 at 6:59 PM, Matthew Knepley<knepley at gmail.com>
> wrote:
> >> > I would ask: why is anything ever split up? Why not just munge
> >> > everything in
> >> > the
> >> > entire Linux distribution into one big fat library?
> >> >
> >> >   Matt
> >>
> >> Mat, that's is not a fair example...
> >
> > I think it is a good one. Things should be pushed to the logical limit to
> > illustrate where
> > they break down.
> >
>
> OK, then tell me... Is the C stdlib split in many pieces? It depends
> on what you define as a library... The headers are split, but the
> binary .so/.dll/.dylib are not... Why? Because this is what is
> convenient for USERS, not for the developers of a C compiler and it
> support libraries...
>

According to this model, we should have one library for everything you ever
use.
Then you would never have to think.

And, as I said, if we want to (optionally) dump everything in a single
library at
the end of the build, I won't oppose that.


> > I think it is a good thing to have clear, logical divisions in programs.
> It
> > is the main tool
> > to control complexity. This is more important than load time, or space,
> or
> > almost anything
> > else. We do not put all of Linux in one library for space or time reasons
> > (witness Knoppix)
> > but to control the complexity.
> >
>
> IMHO, many *.a|*.so files are actually more complex for the end USER.
> Take into account not all people use PETSc makefiles... Some time ago
> I just had to explain a coworker (using Scons for building) why the
> linking of his code was failing (you know, wrong library ordering...)
>

Same comment.


> > We also frequently make errors when these things are not strictly
> enforced.
> > We had a ton
> > of circular dependencies before. Again, this is not an issue of
> correctness
> > (it will work in
> > one big library). It is about controlling complexity, which increases
> > greatly with the number
> > of interconnections and quickly becomes unmanageable when a change in one
> > place can
> > secretly break a dependency in another.
> >
>
> But then you DEVELOPER are pushing complexity on USER's side, just
> because you have fear of making mistakes...


This is not contra to my main point. We enforce developer rules. I do not
really care what face the user sees. In fact, he should be able to choose.


>
> I believe that if we want to control the modularity of the code in
> strict fashion, then all what we need should be:
>
> 1) NEVER EVER use these bare "EXTERN xxxx" in sources, use headers for
> that (even if they are somewhat internal, not exposed to users, just
> to help us to enforce our own policy)
>
> 2) start using some recent (well, 3/4/5 years?) GCC features to
> control the symbol visibility http://gcc.gnu.org/wiki/Visibility.
>
> > I am not opposed to a single build rule at the end which lumps all .o's
> into
> > one honking
> > library. Adam already does think I believe for the true believers at
> Debian.
> > I just don't
> > want this as part of the process. It makes everyone sloppy.
> >
>
> Still, I think lowering complexity for users should be fist,
> preventing ourselves from being sloppy should be second.
>

They are not mutually exclusive. We do not need to change our development
process
or build in order to make OneBigLibrary at the end.

  Matt


> >>
> >> A single library will solve a problem you can exercise with the Python
> >> code below (using a shared libs build)
> >>
> >> import os
> >> PETSC_DIR = os.getenv('PETSC_DIR')
> >> PETSC_ARCH = os.getenv('PETSC_ARCH')
> >> PETSC_LIB_DIR = os.path.join(PETSC_DIR, PETSC_ARCH, 'lib')
> >>
> >> import ctypes
> >> MODE = ctypes.RTLD_LOCAL
> >> #MODE = ctypes.RTLD_GLOBAL
> >> libpetsc    = ctypes.CDLL(os.path.join(PETSC_LIB_DIR, 'libpetsc.so'),
> >> mode=MODE)
> >> libpetscvec = ctypes.CDLL(os.path.join(PETSC_LIB_DIR,
> >> 'libpetscvec.so'), mode=MODE)
> >>
> >>
> >> The only way you can dlopen() PETSc libraries is by using RTLD_GLOBAL
> >> (uncomment an you will see it works in that case).
> >>
> >>
> >> Moreover, see this, just run on my rather old box, with a debug build
> >> and many external packages (= big libraries):
> >>
> >> $ time python -c "from petsc4py import PETSc"
> >> real    0m0.791s
> >> user    0m0.175s
> >> sys     0m0.081s
> >>
> >> $ time python -c "from petsc4py import PETSc"
> >> real    0m0.341s
> >> user    0m0.199s
> >> sys     0m0.072s
> >>
> >>
> >> So the time required to load the whole PETSc (at least what petsc4py
> >> uses, that IMHO is a lot) is really tiny compared to any practical
> >> run.
> >>
> >>
> >>
> >> >
> >> > On Tue, Jun 9, 2009 at 4:55 PM, Jed Brown <jed at 59a2.org> wrote:
> >> >>
> >> >> Barry Smith wrote:
> >> >> >
> >> >> > On Jun 9, 2009, at 4:37 PM, Matthew Knepley wrote:
> >> >> >
> >> >> >> I think its legitimate to only want some of our crap.
> >> >> >
> >> >> >    You only get what you use; if you only use KSP then only the KSP
> >> >> > and
> >> >> > below stuff will be pulled into your program, so what is the
> problem?
> >> >>
> >> >> With shared libs, you always get the whole thing.  Of course, the
> >> >> unused
> >> >> part may only be mapped into virtual memory (thus never physically
> >> >> present).  I suspect it's fairly rare to use less than Mat or KSP at
> >> >> which point the presence of SNES/TS/DM is minimal overhead.  A single
> >> >> lib is certainly easier to find with configure scripts.
> >> >>
> >> >> Jed
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > What most experimenters take for granted before they begin their
> >> > experiments
> >> > is infinitely more interesting than any results to which their
> >> > experiments
> >> > lead.
> >> > -- Norbert Wiener
> >> >
> >>
> >>
> >>
> >> --
> >> Lisandro Dalcín
> >> ---------------
> >> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> >> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> >> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> >> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> >> Tel/Fax: +54-(0)342-451.1594
> >
> >
> >
> > --
> > What most experimenters take for granted before they begin their
> experiments
> > is infinitely more interesting than any results to which their
> experiments
> > lead.
> > -- Norbert Wiener
> >
>
>
>
> --
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>



-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090609/4d0906d3/attachment.html>