<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 3:09 AM, Pauli Virtanen <span dir="ltr"><<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span class=""><br>
<br>
Ralf Gommers kirjoitti 06.03.2018 klo 05:06:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Goal of this email: start a discussion to decide whether we'd be okay with<br>
relying on Numba as a dependency, now or in 1-2 years' time.<br>
</blockquote>
<br></span>
I think the main concerns indeed are portability and maturity.<br>
<br>
The advantages of Numba on the other hand are clear, as it mostly avoids the multiple-language mess.<br>
<br>
We might also want to consider using cffi at some point. Currently, we basically just have Cython, f2py, and hand-written C code for ffi.<br>
<br>
I guess LLVM supports most of the architectures we would be interested in, but e.g. the fact that ARM does not work yet is not so nice. Moreover, libLLVM is 50+ megabyte blob, but maybe today when people run text editors on web browsers instead of vice versa that's not a big deal.<br>
<br>
The idea that we could use `scipy._lib.jit` that's either a noop or Numba jit does not sound good in practice: for code where the JIT is wanted, the performance without it is likely unacceptable.</blockquote><div><br></div><div>I don't think it's performance here that matters. For >99.x% of our users Numba will install just fine, the exceptions being the exotic architectures like POWER8. On those, having SciPy import and work as expected is enough; those functions that are implemented with Numba then run slower - that's at the start <1% of functions we offer for <1% of our userbase.<br><br></div><div>Also, I don't think performance will necessarily be unacceptable. There are a bunch of places in the existing code base where we can throw in @jit and get speedups basically for free. Performance in the noop case will then be what it is today - not great, but apparently also not enough of a problem that someone has attempted to go to Cython.<br><br></div><div>Ralf<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (For PyPy, the no-op decorator in principle could be acceptable, but only with numpypy which IIUC is not production ready currently, cpyext+numpy likely won't be faster than CPython.) Moreover, we presumably would like to use features such as `numba.cfunc`. So as I see it, either Numba is a hard dependency, or we don't use it.<br>
<br>
On maturity: I don't know what is the API stability status for Numba, presumably the basic API is stable.<br>
<br>
Numba debugging also in my experience has several paper cuts, e.g., the compilation and runtime errors are cryptic --- they assume you know how numba works, and don't include such niceties as line numbers or useful tracebacks, etc. Maybe this will improve in coming years.<span class="HOEnZb"><font color="#888888"><br>
<br>
        Pauli</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/scipy-dev</a><br>
</div></div></blockquote></div><br></div></div>