This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [row/column majority] gslclapack


> On Thu, Mar 30, 2006 at 05:24:25PM -0500, James Bergstra wrote:
> > 
> > Can someone explain why we have CblasRowMajor and CblasColMajor?
> > 
> > I just did a little test to convince myself, and indeed (with
> > -lgslcblas) the two following calls seem to produce the same answers
> > in the variable c.
> > 
> >     cblas_dgemm(CblasRowMajor, T2, T1, ...  a, b, c)
> >     cblas_dgemm(CblasColMajor, T2, T1, ...  b, a, c)
> > 
> > T1 and T2 are each one of CblasNoTrans and CblasTrans.
> > 
> > Did I make a mistake?  Are there other BLAS functions for which you
> > need to specify the data format for things to work?
> 
On Thu, Mar 30, 2006 at 06:09:09PM -0600, Linas Vepstas wrote:
> For matrices that are larger than the native L1, L2, and L3 caches 
> on your machine (typically some dozens of KB, 1 MB and 4-16MB
> respectively), you should see (possibly very large) performance
> differences. Performance depends very strongly on memory access
> patterns. 

This answer doesn't make sense to me, because in my example the memory access
patterns are identical.  I'm multiplying the same physical matrices together,
and getting the same physical result.  If one call is slower than the other then
I would think it's a bad implementation.

-- 
james bergstra
http://www-etud.iro.umontreal.ca/~bergstrj


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]