On 3/14/07, Daniel Mahler <[EMAIL PROTECTED]> wrote:
On 3/12/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> I'm not convinced that the broadcasting is causing the slow-downs.
> Currently, the code has two path-ways. One gets called when the inputs
> are scalars which is equivalent to the old code and the second gets
> called when broadcasting is desired. Their should be only a very small
> speed hit because of the check. So, it should be possible to do both
> without great differences in speed.
>
> Perhaps the speed hit is due to something else (like creating 0-d arrays
> from scalars, or something similar). So, in other words, I think the
> problem is fixable, but we need someone who can track down where the
> slowness is coming from.
>
> -Travis
The problem is very easy to reproduce.
What would it take to do the tracking?
I'd like to see this fixed.
Presumably the python profiler is no use since the problem is inside C
code,
which is not my expertise.
Well, it is not creation of scalars per se that is slow.
In [6]: def normal1() :
...: a = normal(0,1,1000)
...: for i in xrange(1000) :
...: b = a[i]
In [7]: def normal2() :
...: for i in xrange(1000) :
...: b = normal(0,1)
In [18]: t1=Timer("normal1()","from __main__ import normal1")
In [19]: t2=Timer("normal2()","from __main__ import normal2")
In [22]: t1.timeit(100)
Out[22]: 0.086430072784423828
In [23]: t2.timeit(100)
Out[23]: 4.276231050491333
Looks to me like the call overhead is dominate and that the fast path is not
nearly as fast as it could be. Either it takes a long time to decide which
path to take or something is getting reinitialized that needn't. Could be
that normals should be special cased but I can't tell till I look at the
code.
Chuck
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
