On Tue, Jun 9, 2009 at 5:19 PM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Jun 9, 2009 at 6:59 PM, Matthew Knepley<<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
</div><div class="im">> I would ask: why is anything ever split up? Why not just munge everything in<br>
> the<br>
> entire Linux distribution into one big fat library?<br>
><br>
> Matt<br>
<br>
</div>Mat, that's is not a fair example...</blockquote><div><br>I think it is a good one. Things should be pushed to the logical limit to illustrate where<br>they break down.<br><br>I think it is a good thing to have clear, logical divisions in programs. It is the main tool<br>
to control complexity. This is more important than load time, or space, or almost anything<br>else. We do not put all of Linux in one library for space or time reasons (witness Knoppix)<br>but to control the complexity.<br>
<br>We also frequently make errors when these things are not strictly enforced. We had a ton<br>of circular dependencies before. Again, this is not an issue of correctness (it will work in<br>one big library). It is about controlling complexity, which increases greatly with the number<br>
of interconnections and quickly becomes unmanageable when a change in one place can<br>secretly break a dependency in another.<br><br>I am not opposed to a single build rule at the end which lumps all .o's into one honking<br>
library. Adam already does think I believe for the true believers at Debian. I just don't<br>want this as part of the process. It makes everyone sloppy.<br><br> Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
A single library will solve a problem you can exercise with the Python<br>
code below (using a shared libs build)<br>
<br>
import os<br>
PETSC_DIR = os.getenv('PETSC_DIR')<br>
PETSC_ARCH = os.getenv('PETSC_ARCH')<br>
PETSC_LIB_DIR = os.path.join(PETSC_DIR, PETSC_ARCH, 'lib')<br>
<br>
import ctypes<br>
MODE = ctypes.RTLD_LOCAL<br>
#MODE = ctypes.RTLD_GLOBAL<br>
libpetsc = ctypes.CDLL(os.path.join(PETSC_LIB_DIR, 'libpetsc.so'), mode=MODE)<br>
libpetscvec = ctypes.CDLL(os.path.join(PETSC_LIB_DIR,<br>
'libpetscvec.so'), mode=MODE)<br>
<br>
<br>
The only way you can dlopen() PETSc libraries is by using RTLD_GLOBAL<br>
(uncomment an you will see it works in that case).<br>
<br>
<br>
Moreover, see this, just run on my rather old box, with a debug build<br>
and many external packages (= big libraries):<br>
<br>
$ time python -c "from petsc4py import PETSc"<br>
real 0m0.791s<br>
user 0m0.175s<br>
sys 0m0.081s<br>
<br>
$ time python -c "from petsc4py import PETSc"<br>
real 0m0.341s<br>
user 0m0.199s<br>
sys 0m0.072s<br>
<br>
<br>
So the time required to load the whole PETSc (at least what petsc4py<br>
uses, that IMHO is a lot) is really tiny compared to any practical<br>
run.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
><br>
> On Tue, Jun 9, 2009 at 4:55 PM, Jed Brown <<a href="mailto:jed@59a2.org">jed@59a2.org</a>> wrote:<br>
>><br>
>> Barry Smith wrote:<br>
>> ><br>
>> > On Jun 9, 2009, at 4:37 PM, Matthew Knepley wrote:<br>
>> ><br>
>> >> I think its legitimate to only want some of our crap.<br>
>> ><br>
>> > You only get what you use; if you only use KSP then only the KSP and<br>
>> > below stuff will be pulled into your program, so what is the problem?<br>
>><br>
>> With shared libs, you always get the whole thing. Of course, the unused<br>
>> part may only be mapped into virtual memory (thus never physically<br>
>> present). I suspect it's fairly rare to use less than Mat or KSP at<br>
>> which point the presence of SNES/TS/DM is minimal overhead. A single<br>
>> lib is certainly easier to find with configure scripts.<br>
>><br>
>> Jed<br>
>><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>