Home > Archive > Fortran > August 2005 > Question about BLAS sgemm function
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Question about BLAS sgemm function
|
|
| Sandra-24 2005-08-06, 10:01 pm |
| Why does the BLAS function sgemm ask for the arguments lda, ldb, and
ldc? As far as I can tell they are used only in error checking and are
unrelated to the actual operation (just looking at the model
implementation) does anybody know why they are included? I don't see
why you need to know how big the underlying arrays are if you have the
dimensions of the subset of it that you're working with. Maybe a
Fortran thing?
I've been given the task of "porting" BLAS to a platform without a
fortran compiler and I've been having a little difficulty understanding
the standard. The document is fairly brief and I haven't discovered any
sort of mailing list or discussion group where I can ask questions
about it.
Any comments much appreciated.
Thanks,
-Sandra
| |
| Richard Maine 2005-08-06, 10:01 pm |
| In article <1123366230.380707.197420@g43g2000cwa.googlegroups.com>,
"Sandra-24" <sandravandale@yahoo.com> wrote:
> Why does the BLAS function sgemm ask for the arguments lda, ldb, and
> ldc? As far as I can tell they are used only in error checking
Um. No.
> I don't see
> why you need to know how big the underlying arrays are if you have the
> dimensions of the subset of it that you're working with. Maybe a
> Fortran thing?
Yes, you could say it is a Fortran thing. You need to know the
underlying array size in order to correctly compute where in memory the
array elements are. This is, of course, critically important.
Because memory addresses are invariably one-dimensional for current
purposes (other schemes exist, particularly in regard to parallel
processing, but that's a different subject), there is a formula to
compute a 1-D memory address for each element. That formula uses the
size of the leading dimension (actually, all except for the last
dimension, but in a 2-D array, that leaves just the leading one).
Mostly this goes back to the lack of dynamic allocation in pre-f90
versions of Fortran. Anyway, that's why so many applications have arrays
that have underlying sizes different from the portion you are working
with. There are other reasons for such differences to exist, but in
pre-f77 days it was almost the normal case.
You have to know the underlying size one way or another, either by
assuming that it is the same as the used size or by passing it as a
separate argument. With f90 assumed-shape arrays, the compiler takes
care of passing all the needed information for you. In f77 and earlier,
you have to do it yourself, sometimes resulting in annoyingly long
argument lists).
| |
| Sandra-24 2005-08-06, 10:01 pm |
| Now I understand, thank you for your help. I am very happy to have
found someone knowledgeable about BLAS here.
Thanks again,
-Sandra
| |
| glen herrmannsfeldt 2005-08-06, 10:01 pm |
| Richard Maine wrote:
> In article <1123366230.380707.197420@g43g2000cwa.googlegroups.com>,
> "Sandra-24" <sandravandale@yahoo.com> wrote:
[color=darkred]
> Um. No.
[color=darkred]
> Yes, you could say it is a Fortran thing. You need to know the
> underlying array size in order to correctly compute where in memory the
> array elements are. This is, of course, critically important.
> Because memory addresses are invariably one-dimensional for current
> purposes (other schemes exist, particularly in regard to parallel
> processing, but that's a different subject), there is a formula to
> compute a 1-D memory address for each element. That formula uses the
> size of the leading dimension (actually, all except for the last
> dimension, but in a 2-D array, that leaves just the leading one).
In C, an array of pointers to arrays is often used in place of
a 2D array, in which case you don't need the size of the underlying
array(s). One reason is that C doesn't supply much support for
normal 2D arrays. (Compile time dimensions only, even in
called subprograms.)
Java only uses the array of reference objects (pointers)
method, though it will do the allocation for you.
Even with dynamic allocation it is sometimes desirable to
use less than the allocated space.
-- glen
| |
| Ron Shepard 2005-08-07, 5:02 pm |
| In article <1123366230.380707.197420@g43g2000cwa.googlegroups.com>,
"Sandra-24" <sandravandale@yahoo.com> wrote:
> Why does the BLAS function sgemm ask for the arguments lda, ldb, and
> ldc? As far as I can tell they are used only in error checking and are
> unrelated to the actual operation (just looking at the model
> implementation) does anybody know why they are included? I don't see
> why you need to know how big the underlying arrays are if you have the
> dimensions of the subset of it that you're working with. Maybe a
> Fortran thing?
>
> I've been given the task of "porting" BLAS to a platform without a
> fortran compiler and I've been having a little difficulty understanding
> the standard. The document is fairly brief and I haven't discovered any
> sort of mailing list or discussion group where I can ask questions
> about it.
>
> Any comments much appreciated.
It is for operating on subblocks of larger matrices. For example,
supposed you have the z(3,3) matrix with elements
a1 a4 a7
a2 a5 a8
a3 a6 a9
and you want to perform some operation on the subblock
* a4 a7
* a5 a8
* * *
You would pass the actual argument z(1,2) and tell sgemm() that it
is a 2x2 array with leading dimension 3. The leading dimension is
necessary in order to know that there are three storage units
between the elements of adjacent columns within a row. In the BLAS
routines, it is assumed that elements within a column of an array
are always stored consecutively.
Have you looked up the BLAS literature references? These
conventions are explained in detail in the document.
I assume you are trying to implement these in assembler. If you
have a C compiler, then maybe everything would be easier if you
ported a fortran compiler (g77, gfortran, etc.) and then just
compiled the fortran source code. That is, if you are going to have
to reimplement BLAS, LINPACK, EISPACK, LAPACK, and some
miscellaneous netlib and homegrown fortran code in another language,
then maybe you should consider porting the appropriate tools rather
than the application code. There are enough subtle differences in
languages (e.g. fortran and C) involving array addressing
conventions, zero-based subscripts rather than arbitrary-based
subscripts, aliasing, and argument symantics, that doing manual
ports by hand is difficult and error-prone.
$.02 -Ron Shepard
| |
|
| Sandra-24 wrote:
>
> Why does the BLAS function sgemm ask for the arguments lda, ldb, and
> ldc? As far as I can tell they are used only in error checking and are
> unrelated to the actual operation (just looking at the model
> implementation) does anybody know why they are included? I don't see
> why you need to know how big the underlying arrays are if you have the
> dimensions of the subset of it that you're working with.
Look up a fairly recent thread, "help with dgemm subroutine in BLAS" -
the poster (Dawn) apparently walked away satisfied, even though she
said, and I quote, "Quite possibly the freakiest analogy I have ever
heard but scarily it helps visualize the problem."
| |
| Jan Vorbrüggen 2005-08-08, 5:03 pm |
| > Why does the BLAS function sgemm ask for the arguments lda, ldb, and
> ldc? As far as I can tell they are used only in error checking and are
> unrelated to the actual operation (just looking at the model
> implementation) does anybody know why they are included? I don't see
> why you need to know how big the underlying arrays are if you have the
> dimensions of the subset of it that you're working with. Maybe a
> Fortran thing?
The real question is why would you be using only a subarray of the under-
lying array. One of the answers to that is performance: On many memory
subsystems, it is a Bad Thing if you access memory in large power-of-2
strides, while your algorithm (think FFT and other divide-et-impera al-
gorithms) might actually prefer such lenghts. The solution is to pad the
array to some satisfying larger number (e.g., 1025 instead of 1024) but
actually only work on the underlying original size.
Jan
| |
| Dave Thompson 2005-08-14, 4:00 am |
| On Sat, 06 Aug 2005 16:30:20 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
<snip>
> In C, an array of pointers to arrays is often used in place of
> a 2D array, in which case you don't need the size of the underlying
> array(s). One reason is that C doesn't supply much support for
> normal 2D arrays. (Compile time dimensions only, even in
> called subprograms.)
>
s/doesn't/didn't/. C99 has variable bounds, equivalent to Ftn
adjustable + automatic + slightly more. Full C99 is not (yet?) widely
implemented, although some features are implemented in some compilers
and this feature in particular is in gcc and was even before '99.
> Java only uses the array of reference objects (pointers)
> method, though it will do the allocation for you.
>
And FWIW PL/I has (always) the equivalent of assumed-shape.
> Even with dynamic allocation it is sometimes desirable to
> use less than the allocated space.
>
> -- glen
- David.Thompson1 at worldnet.att.net
| |
| glen herrmannsfeldt 2005-08-22, 3:57 am |
| Dave Thompson wrote:
> On Sat, 06 Aug 2005 16:30:20 -0700, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
> <snip>
[color=darkred]
> s/doesn't/didn't/. C99 has variable bounds, equivalent to Ftn
> adjustable + automatic + slightly more. Full C99 is not (yet?) widely
> implemented, although some features are implemented in some compilers
> and this feature in particular is in gcc and was even before '99.
Yes, all my C comments are regarding C89 or earlier.
I should make that explicit in my posts.
Now that you mention it, I might have heard about this one,
but I still haven't used it. If Fortran could do it in 1966,
I don't see why C couldn't in 1989.
[color=darkred]
> And FWIW PL/I has (always) the equivalent of assumed-shape.
I do remember calling Fortran from PL/I by specifying
the first element of the array, passed by address, to
avoid the descriptor necessary to do assumed shape calls.
-- glen
|
|
|
|
|