<div dir="ltr">On Thu, Mar 8, 2018 at 5:16 PM, Joshua Wilson <span dir="ltr"><<a href="mailto:josh.craig.wilson@gmail.com" target="_blank">josh.craig.wilson@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> if someone is interested in trying to implement some SciPy functions with Numba implementations<br>
<br>
</span>When this thread started I actually did just that for a small part of<br>
scipy.special. Code is here:<br></blockquote><div><br></div><div>Now that you mention scipy.special, here is another data point with some promising benchmarks, wrapping CEPHES with CFFI:<br><br><a href="https://github.com/poliastro/pycephes#performance">https://github.com/poliastro/pycephes#performance</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://github.com/person142/special" rel="noreferrer" target="_blank">https://github.com/person142/<wbr>special</a><br>
<br>
It currently implements `special.loggamma` and some private functions<br>
in special (sinpi, cospi, polynomial evaluation) that are needed to<br>
support it. I'm currently seeing a factor of 2 slowdown and trying to<br>
figure out why, but I'm very interested in figuring out how to close<br>
the speed gap/porting more functions.<br>
<br>
- Josh<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Thu, Mar 8, 2018 at 8:44 AM, Stanley Seibert <<a href="mailto:sseibert@anaconda.com">sseibert@anaconda.com</a>> wrote:<br>
> TBH, I agree with this general sentiment.  This thread has been very<br>
> valuable to clarify the Numba team's understanding of what the SciPy<br>
> community needs from a compilation solution.  Our trajectory is good, but<br>
> we're not quite there yet for a project that needs to be as conservative<br>
> about dependencies as SciPy.  We will keep working to get there, though.<br>
><br>
> However, if someone is interested in trying to implement some SciPy<br>
> functions with Numba implementations, there's nothing blocking that work in<br>
> a separate repository as an experiment.  (One of the Numba developers has<br>
> already named this hypothetical project "Scumba," which I quite like.)  If<br>
> anyone does decide to try this, please make sure to ping the Numba<br>
> developers on Gitter.  We will learn a great deal from the effort, I think.<br>
><br>
> On Thu, Mar 8, 2018 at 4:00 AM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><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<br>
>> >> and<br>
>> >> get speedups basically for free. Performance in the noop case will then<br>
>> >> be<br>
>> >> what it is today - not great, but apparently also not enough of a<br>
>> >> 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<br>
>> > 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<br>
>> > an<br>
>> > alternative to Cython/C/Fortran, there probably will be a performance<br>
>> > hit in<br>
>> > the ballpark of 100x.<br>
>> ><br>
>> > If we are planning to use numba features more fully, e.g. numba.cfunc<br>
>> > e.g.<br>
>> > to write callback functions, that would also require Numba as a hard<br>
>> > dependency.<br>
>><br>
>> 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>
>> ______________________________<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>
><br>
><br>
><br>
> ______________________________<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>
><br>
______________________________<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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Juan Luis Cano<br></div></div></div></div>
</div></div>