on a 4-years old x86 laptop I have, I usually just cannot build Atlas in Sage. It fails, as it's unable to perform their (in)famous tuning precisely enough.
A replacement for Atlas would be nice, therefore... On Dec 10, 9:21 am, Bill Hart <goodwillh...@googlemail.com> wrote: > So I don't know what is considered a fast time to build BLAS, but on > my machine it was straightforward. I just typed make and it detected > the number of cores, the architecture and built a multithreaded BLAS > and LAPACK (which it automatically downloaded for me). It took about > 90s to build and automatically run some tests (though I have 16 cores > on that machine and it seemed to use them also for the whole build > process automatically). > > The LAPACK it downloaded also seems to be BSD licensed. It's written > in Fortran I believe. > > The documentation says you can customise the build process in various > ways. > > Bill. > > On Dec 10, 1:04 am, Bill Hart <goodwillh...@googlemail.com> wrote: > > > > > On Dec 10, 12:39 am, Bill Hart <goodwillh...@googlemail.com> wrote: > > > > This is *fantastic* news that GotoBlas has been BSD licensed. I've > > > wanted to use it in FLINT for years, and we've just been discussing > > > highly optimised matrix routines (Fredrik Johansson has been writing > > > lots of code too). > > > > But I am slightly confused over the CBLAS interface thing. > > > > It seems that the original BLAS reference implementation was in > > > Fortran f77. In fact, a reference implementation seems to be provided, > > > in Fortran, in the reference directory of GotoBlas. There is also some > > > Fortran test code (presumably to compare the results of the optimised > > > BLAS routines with the reference implementation). From what I can tell > > > most of the GotoBLAS is implemented in C and assembly. > > > > From what I read here: > > > >http://www.inf.bv.tum.de/~heisserer/softwarelab04/doc/blas_report.pdf > > > > the usual problem is you have a BLAS written in Fortran, and you want > > > to call it from C. So you have two options: > > > > 1) Link your C program against the BLAS (implemented in Fortran) and > > > use the Fortran function names in your C program. (I'm unclear on > > > whether some matrix transposes are also required.) This is possible > > > because of a 1-1 correspondence between Fortran and C conventions. > > > There's some name mangling required, Fortran calls by reference, and a > > > few other differences with C. > > > > 2) Use a CBLAS implementation, which provides the same functionality, > > > but with C function names and prototypes which wrap the original > > > Fortran implementation. I understand such a CBLAS interface is > > > provided by ATLAS. So one can link against libatlas and use the C > > > function names without having to worry about the 1-1 correspondence > > > with the Fortran code. > > > Sorry, that should say Fortran _interface_, not Fortran _code_. It > > looks like the BLAS in ATLAS is _implemented_ in C and assembly and > > provides both a Fortran and (proper) CBLAS _interface_. So it is also > > an unusual BLAS in that it is not actually implemented in Fortran > > itself. > > > > E.g: > > > > * using method 1 you'd have dgemm_("n", "n", &m ,&n ,&k ,&alpha, > > > B[0],&ldb, A[0],&lda,&beta, C[0],&ldc); which calls the Fortran > > > function directly from C, mangling everything appropriately. > > > > * using method 2 you'd have cblas_dgemm(Order, TransA, TransB, m, n, > > > k, alpha, a, lda, b, ldb, beta, c, ldc); which calls the C function. > > > > So let's look at which GotoBLAS provides, by looking in it's CBlas > > > interface, in the file cblas.h: > > > > void cblas_dgemm(enum CBLAS_ORDER Order, enum CBLAS_TRANSPOSE TransA, > > > enum CBLAS_TRANSPOSE TransB, blasint M, blasint N, blasint K, > > > double alpha, double *A, blasint lda, double *B, blasint > > > ldb, > > > double beta, double *C, blasint ldc); > > > > So what am I missing here? > > > > I also notice that much of the GotoBLAS functionality seems to be in > > > (hand?) written assembly and C. That is, both the kernel and the > > > (Fortran) interface actually seem to be implemented in C (Is this a > > > case of: a determined programmer can write Fortran in any language? > > > LOL.). > > > > Sorry if I am being completely ignorant here. I've never actually > > > directly used ATLAS, GotoBLAS, f77 BLAS or CBLAS myself, as Sage just > > > provides it for me, so I have no clue what I'm talking about. Is there > > > additional functionality provided by a CBLAS interface not provided by > > > Goto's BLAS? I did read somewhere that ATLAS provides some functions > > > from LAPACK... ah yes, I think I have that right. That is on the ATLAS > > > homepage. Do we use any of those? > > > > Anyhow, big +1 for using Goto if it is at all possible. I'm sure I'll > > > certainly be using snippets of code from Goto in FLINT, assuming I can > > > get the bits I need to compile without a Fortran compiler. > > > > Bill. > > > > On Dec 7, 11:42 pm, Francois Bissey <francois.bis...@canterbury.ac.nz> > > > wrote: > > > > > Seems like I didn't dig deep enough. > > > > > So it isn't actively developed by the TACC > > > > anymore, it is given to the community to > > > > maintain and take over development. > > > > > It only provides f77blas. I guess it would > > > > be possible to create a cblas interface using > > > > f2c but it is not really something anyone would > > > > want to maintain. > > > > > So unless someone can suggest an alternative > > > > cblas implementation as well, gotoblas is not > > > > a viable alternative. > > > > > Francois > > > > > This email may be confidential and subject to legal privilege, it may > > > > not reflect the views of the University of Canterbury, and it is not > > > > guaranteed to be virus free. If you are not an intended recipient, > > > > please notify the sender immediately and erase all copies of the message > > > > and any attachments. > > > > > Please refer tohttp://www.canterbury.ac.nz/emaildisclaimerformore > > > > information. > > > > > winmail.dat > > > > 3KViewDownload -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
