<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[splitting this off into a new thread]<br>
<br>
On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau <<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>> wrote:<br>
[...]<br>
> I also agree the current situation is not sustainable -- as we discussed<br>
> privately before, cythonizing numpy.core is made quite more complicated by<br>
> this. I have myself quite a few issues w/ cythonizing the other parts of<br>
> umath. I would also like to support the static link better than we do now<br>
> (do we know some static link users we can contact to validate our approach<br>
> ?)<br>
><br>
> Currently, what we have in numpy core is the following:<br>
><br>
> numpy.core.multiarray -> compilation units in numpy/core/src/multiarray/ +<br>
> statically link npymath<br>
> numpy.core.umath -> compilation units in numpy/core/src/umath + statically<br>
> link npymath/npysort + some shenanigans to use things in<br>
> numpy.core.multiarray<br>
<br>
There are also shenanigans in the other direction - supposedly umath<br>
is layered "above" multiarray, but in practice there are circular<br>
dependencies (see e.g. np.set_numeric_ops).<br></blockquote><div><br></div><div>Indeed, I am not arguing about merging umath and multiarray.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I would suggest to have a more layered approach, to enable both 'normal'<br>
> build and static build, without polluting the public namespace too much.<br>
> This is an approach followed by most large libraries (e.g. MKL), and is<br>
> fairly flexible.<br>
><br>
> Concretely, we could start by putting more common functionalities (aka the<br>
> 'core' library) into its own static library. The API would be considered<br>
> private to numpy (no stability guaranteed outside numpy), and every exported<br>
> symbol from that library would be decorated appropriately to avoid potential<br>
> clashes (e.g. '_npy_internal_').<br>
<br>
I don't see why we need this multi-layered complexity, though.<br></blockquote><div><br></div><div>For several reasons:<br><br></div><div> - when you want to cythonize either extension, it is much easier to separate it as cython for CPython API, C for the rest.<br></div><div> - if <a href="http://numpy.core.multiarray.so">numpy.core.multiarray.so</a> is built as cython-based .o + a 'large' C static library, it should become much simpler to support static link.<br></div><div> - maybe that's just personal, but I find the whole multiarray + umath quite beyond manageable in terms of intertwined complexity. You may argue it is not that big, and we all have different preferences in terms of organization, but if I look at the binary size of multiarray + umath, it is quite larger than the median size of the .so I have in my /usr/lib.<br><br></div><div>I am also hoping that splitting up numpy.core in separate elements that communicate through internal APIs would make participating into numpy easier.<br><br></div><div>We could also swap the argument: assuming it does not make the build more complex, and that it does help static linking, why not doing it ?<br><br></div><div>David<br></div></div></div></div>