<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 2:00 AM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Thu, Mar 8, 2018 at 9:38 AM, Pauli Virtanen <<a href="mailto:pav@iki.fi">pav@iki.fi</a>> wrote:<br>
> Ralf Gommers kirjoitti 08.03.2018 klo 08:04:<br>
> [clip]<br>
>><br>
>> Also, I don't think performance will necessarily be unacceptable. There<br>
>> are<br>
>> a bunch of places in the existing code base where we can throw in @jit and<br>
>> get speedups basically for free. Performance in the noop case will then be<br>
>> what it is today - not great, but apparently also not enough of a problem<br>
>> that someone has attempted to go to Cython.<br>
><br>
><br>
> I guess you agree that Numba would regardless be declared a dependency in<br>
> setup.py? People on unsupported arches can edit it away manually.<br>
><br>
> For computational tight loops operating on arrays when Numba is used as an<br>
> alternative to Cython/C/Fortran, there probably will be a performance hit in<br>
> the ballpark of 100x.<br>
><br>
> If we are planning to use numba features more fully, e.g. numba.cfunc e.g.<br>
> to write callback functions, that would also require Numba as a hard<br>
> dependency.<br>
<br>
</span>If we were at the top of the stack, like pystatsmodels, then this<br>
would be reasonable, but, if we make numba a dependency, that makes<br>
numba a dependency for almost anyone doing scientific computing.  I<br>
think we do have to care about people not running on Intel.   If we<br>
make numba an optional dependency, it gives us an additional<br>
maintenance burden, because we'd have to check for each numba segment,<br>
whether it is going to be disabling for a user without numba.<br>
<br>
Is there anything we have at the moment where Cython won't get us into<br>
the ballpark?</blockquote><div><br></div><div>That's pretty much an irrelevant question - Cython is typically 2x to 4x slower so that's in the ballpark, however the problem is ease of use with Cython is so much worse that a lot of code simply won't get ported and just stays pure Python.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  If not, my preference would be to wait for a year or<br>
so, to see how things turn out.<br></blockquote><div><br></div><div>Yes, agreed. The consensus seems to be "no" for now - we can revisit once ARM & co are better supported.<br><br></div><div>Ralf<br><br></div></div></div></div>