why not a single PETSc library

Matthew Knepley knepley at gmail.com
Tue Jun 9 18:02:23 CDT 2009


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.

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.

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.

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.

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090609/6a690758/attachment.html>


More information about the petsc-dev mailing list