A Tuesday 11 January 2011 06:45:28 Mark Wiebe escrigué:
> On Mon, Jan 10, 2011 at 11:35 AM, Mark Wiebe
wrote:
> > I'm a bit curious why the jump from 1 to 2 threads is scaling so
> > poorly.
> >
> > Your timings have improvement factors of 1.85, 1.68, 1.64, and
> > 1.79. Since
> >
> > the co
A Monday 10 January 2011 19:29:33 Mark Wiebe escrigué:
> > so, the new code is just < 5% slower. I suppose that removing the
> > NPY_ITER_ALIGNED flag would give us a bit more performance, but
> > that's great as it is now. How did you do that? Your new_iter
> > branch in NumPy already deals wit
On Mon, Jan 10, 2011 at 11:35 AM, Mark Wiebe wrote:
> I'm a bit curious why the jump from 1 to 2 threads is scaling so poorly.
> Your timings have improvement factors of 1.85, 1.68, 1.64, and 1.79. Since
> the computation is trivial data parallelism, and I believe it's still pretty
> far off th
I'm a bit curious why the jump from 1 to 2 threads is scaling so poorly.
Your timings have improvement factors of 1.85, 1.68, 1.64, and 1.79. Since
the computation is trivial data parallelism, and I believe it's still pretty
far off the memory bandwidth limit, I would expect a speedup of 1.95 or
On Mon, Jan 10, 2011 at 9:47 AM, Francesc Alted wrote:
>
>
> so, the new code is just < 5% slower. I suppose that removing the
> NPY_ITER_ALIGNED flag would give us a bit more performance, but that's
> great as it is now. How did you do that? Your new_iter branch in NumPy
> already deals with
A Monday 10 January 2011 17:54:16 Mark Wiebe escrigué:
> > Apparently, you forgot to add the new_iterator_pywrap.h file.
>
> Oops, that's added now.
Excellent. It works now.
> The aligned case should just be a matter of conditionally removing
> the NPY_ITER_ALIGNED flag in two places.
Wow, t
On Mon, Jan 10, 2011 at 2:05 AM, Francesc Alted wrote:
>
>
> Your patch looks mostly fine to my eyes; good job! Unfortunately, I've
> been unable to compile your new_iterator branch of NumPy:
>
> numpy/core/src/multiarray/multiarraymodule.c:45:33: fatal error:
> new_iterator_pywrap.h: El fitxer
A Monday 10 January 2011 11:05:27 Francesc Alted escrigué:
> Also, I'd like to try out the new thread scheduling that you
> suggested to me privately (i.e. T0T1T0T1... vs T0T0...T1T1...).
I've just implemented the new partition schema in numexpr
(T0T0...T1T1..., being the original T0T1T0T1...).
A Sunday 09 January 2011 23:45:02 Mark Wiebe escrigué:
> As a benchmark of C-based iterator usage and to make it work properly
> in a multi-threaded context, I've updated numexpr to use the new
> iterator. In addition to some performance improvements, this also
> made it easy to add optional out=
That's right, essentially all I've done is replaced the code that handled
preparing the arrays and producing blocks of values for the inner loops.
There are three new parameters to evaluate_iter as well. It has an "out="
parameter just like ufuncs do, an "order=" parameter which controls the
layo
Is evaluate_iter basically numpexpr but using your numpy branch or are there
other changes?
On Sun, Jan 9, 2011 at 2:45 PM, Mark Wiebe wrote:
> As a benchmark of C-based iterator usage and to make it work properly in a
> multi-threaded context, I've updated numexpr to use the new iterator. In
>
As a benchmark of C-based iterator usage and to make it work properly in a
multi-threaded context, I've updated numexpr to use the new iterator. In
addition to some performance improvements, this also made it easy to add
optional out= and order= parameters to the evaluate function. The numexpr
re
12 matches
Mail list logo
