On 11/09/2012 11:57 PM, Matthieu Brucher wrote:
> Hi,
>
> A.A slower than A.A' is not a surprise for me. The latter is far more
> cache friendly that the former. Everything follows cache lines, so it is
> faster than something that will use one element from each cache line. In
> fact it is exactly
Well I have proof we're going things right! And it also shows the
power of MKL...
I checked with EPD and my python snippet (see also my first email),
and all 4 timings are the same...
However, if this behavior is the right one, then my python snippet
should get the same trend. But it's not.
So I
In this case it's even possible the blas is being smart enough to notice
that you've passed it the same pointer twice with the transpose switch on
one of them, and is just skipping half the multiplies since the output is
provably symmetric. Don't know if they actually do that but...
-n
On 9 Nov 20
On Fri, 2012-11-09 at 14:52 -0800, Nicolas SCHEFFER wrote:
> Ok: comparing apples to apples. I'm clueless on my observations and
> would need input from you guys.
>
> Using ATLAS 3.10, numpy with and without my changes, I'm getting these
> timings and comparisons.
>
> #
> #I. Generate matrices us
Oh, about the differences. If there is something like cache blocking inside
ATLAS (which would make sense), the MAD are not in exactly the same order
and this would lead to some differences. You need to compare the MSE/sum of
values squared to the machine precision.
Cheers,
2012/11/9 Matthieu Br
Hi,
A.A slower than A.A' is not a surprise for me. The latter is far more cache
friendly that the former. Everything follows cache lines, so it is faster
than something that will use one element from each cache line. In fact it
is exactly what "proves" that the new version is correct.
Good job (if
Ok: comparing apples to apples. I'm clueless on my observations and
would need input from you guys.
Using ATLAS 3.10, numpy with and without my changes, I'm getting these
timings and comparisons.
#
#I. Generate matrices using regular dot:
#
big = np.array(np.random.randn(2000, 2000), 'f');
np.sav
I too encourage users to use scipy.linalg for speed and robustness
(hence calling this scipy.dot), but it just brings so much confusion!
When using the scipy + numpy ecosystem, you'd almost want everything
be done with scipy so that you get the best implementation in all
cases: scipy.zeros(), scipy
On Tue, 25 Sep 2012 07:23:54 -0600, Charles R Harris wrote:
> On Tue, Sep 25, 2012 at 6:50 AM, Nathaniel Smith wrote:
>
>> On Tue, Sep 25, 2012 at 12:31 PM, Sturla Molden
>> wrote:
>> > On 25.09.2012 11:38, Nathaniel Smith wrote:
>> >
>> >> Implementing a ring buffer on top of ndarray would be
On Fri, Nov 9, 2012 at 2:17 PM, Alan G Isaac wrote:
> I just noticed that 1.7 is scheduled to add a random.choice function.
> I wonder if the best structure has been chosen. Specifically, it does
> not provide for array flattening, and it does not provide for subarray
> choice.
I think in terms
On Fri, Nov 9, 2012 at 4:25 PM, Gael Varoquaux
wrote:
> On Fri, Nov 09, 2012 at 03:12:42PM +, Nathaniel Smith wrote:
>> But what if someone compiles numpy against an optimized blas (mkl,
>> say) and then compiles SciPy against the reference blas? What do you
>> do then!? ;-)
>
> This could hap
On Fri, Nov 9, 2012 at 9:44 AM, Ralf Gommers wrote:
>
>
>
> On Wed, Nov 7, 2012 at 7:28 PM, Filipe Pires Alvarenga Fernandes <
> ocef...@gmail.com> wrote:
>
>> Hi I am trying to compile numpy with gcc 4.7.1 and I am having the
>> following issue.
>>
>> "RuntimeError: Broken toolchain: cannot link
On Wed, Nov 7, 2012 at 7:28 PM, Filipe Pires Alvarenga Fernandes <
ocef...@gmail.com> wrote:
> Hi I am trying to compile numpy with gcc 4.7.1 and I am having the
> following issue.
>
> "RuntimeError: Broken toolchain: cannot link a simple C program"
>
Do you have Python development headers instal
On Fri, Nov 09, 2012 at 03:12:42PM +, Nathaniel Smith wrote:
> But what if someone compiles numpy against an optimized blas (mkl,
> say) and then compiles SciPy against the reference blas? What do you
> do then!? ;-)
This could happen. But the converse happens very often. What happens is
that
On Fri, Nov 9, 2012 at 10:20 AM, Nathaniel Smith wrote:
> On Fri, Nov 9, 2012 at 2:45 PM, Frédéric Bastien wrote:
> >
> >
> >
> > On Fri, Nov 9, 2012 at 3:32 AM, Nathaniel Smith wrote:
> >>
> >> On Fri, Nov 9, 2012 at 6:18 AM, Nicolas SCHEFFER
> >> wrote:
> >> > Fred,
> >> >
> >> > Thanks for
On Fri, Nov 9, 2012 at 2:45 PM, Frédéric Bastien wrote:
>
>
>
> On Fri, Nov 9, 2012 at 3:32 AM, Nathaniel Smith wrote:
>>
>> On Fri, Nov 9, 2012 at 6:18 AM, Nicolas SCHEFFER
>> wrote:
>> > Fred,
>> >
>> > Thanks for the advice.
>> > The code will only affect the part in _dotblas.c where gemm is
On 9 Nov 2012 08:48, "Gael Varoquaux" wrote:
>
> On Thu, Nov 08, 2012 at 11:29:19AM -0600, Anthony Scopatz wrote:
> > Indeed, there is no reason not to make this available in NumPy.
>
> > +1, I agree, this should be a fix in numpy, not scipy.
>
> I agree.
>
> My point was a bit of a side issue
On Fri, Nov 9, 2012 at 3:32 AM, Nathaniel Smith wrote:
> On Fri, Nov 9, 2012 at 6:18 AM, Nicolas SCHEFFER
> wrote:
> > Fred,
> >
> > Thanks for the advice.
> > The code will only affect the part in _dotblas.c where gemm is called.
> > There's tons of check before that make sure both matrices are
I just noticed that 1.7 is scheduled to add a random.choice function.
I wonder if the best structure has been chosen. Specifically, it does
not provide for array flattening, and it does not provide for subarray
choice.
Back in 2006 (?) Robert Kern suggested something like the below
(forgive any m
Hi,
It's really good to see this work being done.
It would be great if this could somehow be put also into the np.einsum
function, which currently doesn't even use blas, and is consequently
substantially slower than current np.dot (timings on
http://mail.scipy.org/pipermail/numpy-discussion/2012-O
On Thu, Nov 08, 2012 at 11:29:19AM -0600, Anthony Scopatz wrote:
> Indeed, there is no reason not to make this available in NumPy.
> +1, I agree, this should be a fix in numpy, not scipy.
I agree.
My point was a bit of a side issue: given a user's computer, I have no
garantee that numpy will
On Fri, Nov 9, 2012 at 6:18 AM, Nicolas SCHEFFER
wrote:
> Fred,
>
> Thanks for the advice.
> The code will only affect the part in _dotblas.c where gemm is called.
> There's tons of check before that make sure both matrices are of ndim 2.
> We should check though if we can do these tricks in other
22 matches
Mail list logo
