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

Reply via email to