On Tue, Jun 9, 2009 at 7:40 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 8:02 PM, Matthew Knepley<<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Tue, Jun 9, 2009 at 5:19 PM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jun 9, 2009 at 6:59 PM, Matthew Knepley<<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
>> > I would ask: why is anything ever split up? Why not just munge<br>
>> > everything in<br>
>> > the<br>
>> > entire Linux distribution into one big fat library?<br>
>> ><br>
>> >   Matt<br>
>><br>
>> Mat, that's is not a fair example...<br>
><br>
> I think it is a good one. Things should be pushed to the logical limit to<br>
> illustrate where<br>
> they break down.<br>
><br>
<br>
</div>OK, then tell me... Is the C stdlib split in many pieces? It depends<br>
on what you define as a library... The headers are split, but the<br>
binary .so/.dll/.dylib are not... Why? Because this is what is<br>
convenient for USERS, not for the developers of a C compiler and it<br>
support libraries...<br><div class="im"></div></blockquote><div><br>According to this model, we should have one library for everything you ever use.<br>Then you would never have to think.<br><br>And, as I said, if we want to (optionally) dump everything in a single library at<br>
the end of the build, I won't oppose that.<br> </div><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">
> I think it is a good thing to have clear, logical divisions in programs. It<br>
> is the main tool<br>
> to control complexity. This is more important than load time, or space, or<br>
> almost anything<br>
> else. We do not put all of Linux in one library for space or time reasons<br>
> (witness Knoppix)<br>
> but to control the complexity.<br>
><br>
<br>
</div>IMHO, many *.a|*.so files are actually more complex for the end USER.<br>
Take into account not all people use PETSc makefiles... Some time ago<br>
I just had to explain a coworker (using Scons for building) why the<br>
linking of his code was failing (you know, wrong library ordering...)<br><div class="im"></div></blockquote><div><br>Same comment.<br> </div><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">
> We also frequently make errors when these things are not strictly enforced.<br>
> We had a ton<br>
> of circular dependencies before. Again, this is not an issue of correctness<br>
> (it will work in<br>
> one big library). It is about controlling complexity, which increases<br>
> greatly with the number<br>
> of interconnections and quickly becomes unmanageable when a change in one<br>
> place can<br>
> secretly break a dependency in another.<br>
><br>
<br>
</div>But then you DEVELOPER are pushing complexity on USER's side, just<br>
because you have fear of making mistakes...</blockquote><div><br>This is not contra to my main point. We enforce developer rules. I do not<br>really care what face the user sees. In fact, he should be able to choose.<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>
I believe that if we want to control the modularity of the code in<br>
strict fashion, then all what we need should be:<br>
<br>
1) NEVER EVER use these bare "EXTERN xxxx" in sources, use headers for<br>
that (even if they are somewhat internal, not exposed to users, just<br>
to help us to enforce our own policy)<br>
<br>
2) start using some recent (well, 3/4/5 years?) GCC features to<br>
control the symbol visibility <a href="http://gcc.gnu.org/wiki/Visibility" target="_blank">http://gcc.gnu.org/wiki/Visibility</a>.<br>
<div class="im"><br>
> I am not opposed to a single build rule at the end which lumps all .o's into<br>
> one honking<br>
> library. Adam already does think I believe for the true believers at Debian.<br>
> I just don't<br>
> want this as part of the process. It makes everyone sloppy.<br>
><br>
<br>
</div>Still, I think lowering complexity for users should be fist,<br>
preventing ourselves from being sloppy should be second.<br><div><div class="h5"></div></div></blockquote><div><br>They are not mutually exclusive. We do not need to change our development process<br>or build in order to make OneBigLibrary at the end.<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;"><div><div class="h5">
>><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'),<br>
>> 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>
>><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<br>
>> >> > 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<br>
>> >> 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<br>
>> > experiments<br>
>> > is infinitely more interesting than any results to which their<br>
>> > experiments<br>
>> > lead.<br>
>> > -- Norbert Wiener<br>
>> ><br>
>><br>
>><br>
>><br>
>> --<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>
><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>--<br>
<div><div></div><div class="h5">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>
</div></div></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>