[Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars
cournape at gmail.com
Thu May 2 08:42:13 EDT 2013
On Thu, May 2, 2013 at 11:26 AM, Arink Verma <arinkverma at iitrpr.ac.in> wrote:
> Yes, we need to ensure that..
> Code generator can be made, which can create code for table of registered
> dtype during build time itself.
So dtypes can be registered at runtime as well. In an ideal world,
'native' numpy types would not be special cases. This is too big for a
GSoC, but we should make sure we don't make it worse.
> Also at present there lot of duplicate code that attempts to work around
> these slow paths, simplification of that code is also required.
That there is room for consolidation would be an understatement :)
> On Thu, May 2, 2013 at 10:12 AM, David Cournapeau <cournape at gmail.com>
>> 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
>> > value.
>> > @Chuck
>> > Yes I did some profiling with oprofiler for "python -m timeit -n 1000000
>> > -s
>> > '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
>> > the
>> > data that the operation is being performed on. In scalar, we can send
>> > best
>> > 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
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
More information about the NumPy-Discussion