This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: [libgfortran/patch] matmul rewritten for speed


On Mon, Nov 15, 2004 at 07:31:54PM -0500, Steven G. Johnson wrote:
> Scott Robert Ladd wrote:
> >Using BLAS would add an external dependency to the compiler -- anyone 
> >using MATMUL would need to have BLAS installed.
> 
> I understand the necessity of bundling a simple baseline BLAS 
> implementation -- and you are essentially doing this already.  What 
> doesn't make sense to me is to implement BLAS *functionality* but not to 
> use the BLAS *API* so that faster libraries can be dropped in.
> 
> (Many GNU/Linux distros will probably do the substitution for you, since 
> they typically already include an optimized BLAS like ATLAS already.)
> 
> Please join the rest of the linear-algebra world and follow the standard 
> API for these operations.

I agree. I think that as long as we strive for a relatively simple and
portable implementation (which is an admirable goal in itself), atlas
or a vendor-tuned blas library will wipe the floor with gfortran
intrinsics performance-wise.

As for what others are doing, at least Absoft marketing material
claims that their MATMUL is a wrapper around blas. I suspect the other
commercial vendors are doing the same.

Scott does have a good point though, we can't require user to also
download and install a separate blas library.

IMHO, a solution could be something like

1) Add some cpp magic so that the user can choose which implementation
to use at compile time (configure --with-blas=/usr/lib), e.g. matmul
would essentially look like

#ifdef BLAS
	// call BLAS
#else
	// current builtin implementation
#endif

2) Replace the current implementation with calls to blas, and include
the public domain reference blas library in the gcc distribution (like
libgmp and others). Configure automatically searches the usual
suspects (/usr/lib etc.) for an optimized blas, and falls back on the
reference implementation if none is found.

My personal favourite being #2, as it seems simpler and tracking and
fixing bugs ought to be simpler as one wouldn't have to check two
separate versions. One problem could be including the blas library in
the distribution, would this be allowed as gcc is already in stage 3?
Gfortran does have some kind of exception to the normal stage 3 rules,
right?

Anyways, if you guys think one of the above sounds like a good idea, I
can volunteer some time to try to implement it.

-- 
Janne Blomqvist


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