<div dir="ltr">TBH, I agree with this general sentiment.  This thread has been very valuable to clarify the Numba team's understanding of what the SciPy community needs from a compilation solution.  Our trajectory is good, but we're not quite there yet for a project that needs to be as conservative about dependencies as SciPy.  We will keep working to get there, though.<div><br></div><div>However, if someone is interested in trying to implement some SciPy functions with Numba implementations, there's nothing blocking that work in a separate repository as an experiment.  (One of the Numba developers has already named this hypothetical project "Scumba," which I quite like.)  If anyone does decide to try this, please make sure to ping the Numba developers on Gitter.  We will learn a great deal from the effort, I think.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 4: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?  If not, my preference would be to wait for a year or<br>
so, to see how things turn out.<br>
<br>
Cheers,<br>
<br>
Matthew<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
</div></div></blockquote></div><br></div>