why not a single PETSc library

[Lisandro Dalcin]

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

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


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

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.



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