Den 13.02.2011 04:30, skrev Travis Oliphant:
One of the advantages of an open source community is that different
needs get addressed by the people who need them. So, if you really
need a faster sum and are willing to do the hard work to make it
happen (or convince someone else to do it for
Den 13.02.2011 01:02, skrev eat:
Now, I'm not pretending to know what kind of a person a 'typical'
numpy user is. But I'm assuming that there just exists more than me
with roughly similar questions in their (our) minds and who wish to
utilize numpy more 'pythonic; all batteries included' way.
I think everybody would be happy if .sum() were as fast as possible, and
patches for review are always welcome. There are distinct things that could
be done to improve the performance of ufuncs and their methods as several
people have shown.In fact, there is a lot of low-hanging fruit ins
Hi Sturla,
On Sat, Feb 12, 2011 at 5:38 PM, Sturla Molden wrote:
> Den 10.02.2011 16:29, skrev eat:
> > One would expect sum to outperform dot with a clear marginal. Does
> > there exixts any 'tricks' to increase the performance of sum?
>
First of all, thanks for you still replying. Well, I'm st
Den 10.02.2011 16:29, skrev eat:
> One would expect sum to outperform dot with a clear marginal. Does
> there exixts any 'tricks' to increase the performance of sum?
I see that others have ansvered already. The ufunc np.sum is not going
going to beat np.dot. You are racing the heavy machinery of
Thu, 10 Feb 2011 20:49:28 +, Pauli Virtanen wrote:
[clip]
> 1. Check first if the bottleneck is in the inner reduction loop
> (function DOUBLE_add in loops.c.src:712) or in the outer iteration
> (function PyUFunc_ReductionOp in ufunc_object.c:2781).
> 2. If it's in the inner loop, some optim
Hi,
On Fri, Feb 11, 2011 at 12:08 AM, Robert Kern wrote:
> On Thu, Feb 10, 2011 at 15:32, eat wrote:
> > Hi Robert,
> >
> > On Thu, Feb 10, 2011 at 10:58 PM, Robert Kern
> wrote:
> >>
> >> On Thu, Feb 10, 2011 at 14:29, eat wrote:
> >> > Hi Robert,
> >> >
> >> > On Thu, Feb 10, 2011 at 8:16
On Thu, Feb 10, 2011 at 3:08 PM, Robert Kern wrote:
> On Thu, Feb 10, 2011 at 15:32, eat wrote:
> > Hi Robert,
> >
> > On Thu, Feb 10, 2011 at 10:58 PM, Robert Kern
> wrote:
> >>
> >> On Thu, Feb 10, 2011 at 14:29, eat wrote:
> >> > Hi Robert,
> >> >
> >> > On Thu, Feb 10, 2011 at 8:16 PM, Rob
On Thu, Feb 10, 2011 at 2:26 PM, Mark Wiebe wrote:
> On Thu, Feb 10, 2011 at 10:31 AM, Pauli Virtanen wrote:
>
>> Thu, 10 Feb 2011 12:16:12 -0600, Robert Kern wrote:
>> [clip]
>> > One thing that might be worthwhile is to make
>> > implementations of sum() and cumsum() that avoid the ufunc machi
On Thu, Feb 10, 2011 at 15:32, eat wrote:
> Hi Robert,
>
> On Thu, Feb 10, 2011 at 10:58 PM, Robert Kern wrote:
>>
>> On Thu, Feb 10, 2011 at 14:29, eat wrote:
>> > Hi Robert,
>> >
>> > On Thu, Feb 10, 2011 at 8:16 PM, Robert Kern
>> > wrote:
>> >>
>> >> On Thu, Feb 10, 2011 at 11:53, eat wrot
Hi Robert,
On Thu, Feb 10, 2011 at 10:58 PM, Robert Kern wrote:
> On Thu, Feb 10, 2011 at 14:29, eat wrote:
> > Hi Robert,
> >
> > On Thu, Feb 10, 2011 at 8:16 PM, Robert Kern
> wrote:
> >>
> >> On Thu, Feb 10, 2011 at 11:53, eat wrote:
> >> > Thanks Chuck,
> >> >
> >> > for replying. But don
On Thu, Feb 10, 2011 at 10:31 AM, Pauli Virtanen wrote:
> Thu, 10 Feb 2011 12:16:12 -0600, Robert Kern wrote:
> [clip]
> > One thing that might be worthwhile is to make
> > implementations of sum() and cumsum() that avoid the ufunc machinery and
> > do their iterations more quickly, at least for
On Thu, Feb 10, 2011 at 14:51, Joshua Holbrook wrote:
> Maybe I'm missing something, but why not just implement sum() using
> dot() and ones() ?
You can't do everything that sum() does with just dot() and ones().
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harml
On Thu, Feb 10, 2011 at 14:29, eat wrote:
> Hi Robert,
>
> On Thu, Feb 10, 2011 at 8:16 PM, Robert Kern wrote:
>>
>> On Thu, Feb 10, 2011 at 11:53, eat wrote:
>> > Thanks Chuck,
>> >
>> > for replying. But don't you still feel very odd that dot outperforms sum
>> > in
>> > your machine? Just to
Maybe I'm missing something, but why not just implement sum() using
dot() and ones() ?
--Josh
On Thu, Feb 10, 2011 at 11:49 AM, Pauli Virtanen wrote:
> On Thu, 10 Feb 2011 22:38:52 +0200, eat wrote:
> [clip]
>> I hope so. Please suggest if there's anything that I can do to further
>> advance thi
On Thu, 10 Feb 2011 22:38:52 +0200, eat wrote:
[clip]
> I hope so. Please suggest if there's anything that I can do to further
> advance this. (My C skills are allready bit rusty, but at any higher
> level I'll try my best to contribute).
If someone wants to try to improve the situation, here's a
Hi Pauli,
On Thu, Feb 10, 2011 at 8:31 PM, Pauli Virtanen wrote:
> Thu, 10 Feb 2011 12:16:12 -0600, Robert Kern wrote:
> [clip]
> > One thing that might be worthwhile is to make
> > implementations of sum() and cumsum() that avoid the ufunc machinery and
> > do their iterations more quickly, at
Hi Robert,
On Thu, Feb 10, 2011 at 8:16 PM, Robert Kern wrote:
> On Thu, Feb 10, 2011 at 11:53, eat wrote:
> > Thanks Chuck,
> >
> > for replying. But don't you still feel very odd that dot outperforms sum
> in
> > your machine? Just to get it simply; why sum can't outperform dot?
> Whatever
>
Thu, 10 Feb 2011 12:16:12 -0600, Robert Kern wrote:
[clip]
> One thing that might be worthwhile is to make
> implementations of sum() and cumsum() that avoid the ufunc machinery and
> do their iterations more quickly, at least for some common combinations
> of dtype and contiguity.
I wonder what i
On Thu, Feb 10, 2011 at 11:53, eat wrote:
> Thanks Chuck,
>
> for replying. But don't you still feel very odd that dot outperforms sum in
> your machine? Just to get it simply; why sum can't outperform dot? Whatever
> architecture (computer, cache) you have, it don't make any sense at all that
> w
Thanks Chuck,
for replying. But don't you still feel very odd that dot outperforms sum in
your machine? Just to get it simply; why sum can't outperform dot? Whatever
architecture (computer, cache) you have, it don't make any sense at all that
when performing significantly less instructions, you'll
On Thu, Feb 10, 2011 at 8:29 AM, eat wrote:
> Hi,
>
> Observing following performance:
> In []: m= 1e5
> In []: n= 1e2
> In []: o= ones(n)
> In []: M= randn(m, n)
> In []: timeit M.sum(1)
> 10 loops, best of 3: 38.3 ms per loop
> In []: timeit dot(M, o)
> 10 loops, best of 3: 21.1 ms per loop
>
>
Hi,
Observing following performance:
In []: m= 1e5
In []: n= 1e2
In []: o= ones(n)
In []: M= randn(m, n)
In []: timeit M.sum(1)
10 loops, best of 3: 38.3 ms per loop
In []: timeit dot(M, o)
10 loops, best of 3: 21.1 ms per loop
In []: m= 1e2
In []: n= 1e5
In []: o= ones(n)
In []: M= randn(m, n)
I
23 matches
Mail list logo
