[Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars
arinkverma at iitrpr.ac.in
Thu May 2 06:26:58 EDT 2013
Yes, we need to ensure that..
Code generator can be made, which can create code for table of registered
dtype during build time itself.
Also at present there lot of duplicate code that attempts to work around
these slow paths, simplification of that code is also required.
On Thu, May 2, 2013 at 10:12 AM, David Cournapeau <cournape at gmail.com>wrote:
> On Thu, May 2, 2013 at 5:25 AM, Arink Verma <arinkverma at iitrpr.ac.in>
> > @Raul
> > I will pull new version, and try to include that also.
> > What is wrong with macros for inline function?
> > Yes, time for ufunc is reduced to almost half, for lookup table, I am
> > generating key from argument type and returning the appropriated
> > @Chuck
> > Yes I did some profiling with oprofiler for "python -m timeit -n 1000000
> > 'import numpy as np;x = np.asarray(1.0)' 'x+x'". see data sheet.
> > As every time a ufunc is invoked, the code has to check every single data
> > type possible (bool, int, double, etc) until if finds the best match for
> > data that the operation is being performed on. In scalar, we can send
> > match, from pre-populated table. At present the implementation is not
> > well-structured and support only addition for int+int and float+float.
> You are pointing out something that may well be the main difficulty:
> the code there is messy, and we need to ensure that optimisations
> don't preclude later extensions (especially with regard to new dtype
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
Computer Science and Engineering
Indian Institute of Technology Ropar
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion