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 <courn...@gmail.com>wrote: > On Thu, May 2, 2013 at 5:25 AM, Arink Verma <arinkve...@iitrpr.ac.in> > wrote: > > @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.[1] > > > > @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.[2] > > > > 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. > [1] > > 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 > addition). > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Arink Computer Science and Engineering Indian Institute of Technology Ropar www.arinkverma.in
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
