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@gmail.com> wrote:
On Thu, May 2, 2013 at 5:25 AM, Arink Verma <arinkverma@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