Re: Knowing which BLAS, LAPACK,... subroutine are called

[Jordi Gutiérrez Hermoso-2]

On 28 January 2013 16:29, c. <[hidden email]> wrote:
>
> On 28 Jan 2013, at 18:03, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
>
>> In fact, I would welcome a patch to conditionally enable at compile
>> time this debugging output [for displaying which F77 functions get
>> called].
>
> Well, here's the patch.
[snip]
> feel free to push the changeset if you like it or ignore it if you
> don't

I like it, except I wouldn't use a warning to display this. Perhaps
just octave_stdout? It does have the convenience of being easier to
turn on and off with the usual warning mechanism, though.

- Jordi G. H.

[John W. Eaton]

On 28-Jan-2013, Jordi Gutiérrez Hermoso wrote:

| On 28 January 2013 16:29, c. <[hidden email]> wrote:
| >
| > On 28 Jan 2013, at 18:03, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
| >
| >> In fact, I would welcome a patch to conditionally enable at compile
| >> time this debugging output [for displaying which F77 functions get
| >> called].
| >
| > Well, here's the patch.
| [snip]
| > feel free to push the changeset if you like it or ignore it if you
| > don't
|
| I like it, except I wouldn't use a warning to display this. Perhaps
| just octave_stdout? It does have the convenience of being easier to
| turn on and off with the usual warning mechanism, though.

I'm not completely opposed to this idea, but I think it is a little
odd to target all F77 functions.  The proposed change will show more
than just calls to BLAS and LAPACK functions and will stop working if
we change Octave to use a C interface to the BLAS and LAPACK instead
of the current Fortran interface.  Also, in many cases, we call the
same routine twice (once to get the work array dimensions and once to
perform the calculation) so the output will be somewhat more verbose
than necessary.  Finally, I think it will be hard to follow exactly
what is happening for complicated expressions (you'll get a lot of
output without knowing precisely which subexpression is responsible
for each call) and you'll need to be very familiar with the BLAS and
LAPACK libraries to understand the output.  I know it would be more
work to implement, but I think it would be better to have output that
looks something like this:

  calling DSYRK ("U", "T", 10, 10, 1.0, A(10,10), 10, 0.0, c, 10)
  called from:
    foo at line 123, column 45
    bar at line 678, column 9

and to limit this to selected BLAS or LAPACK functions, not every
function call that uses the F77_XFCN macro.

If you do want to go with the simpler change, then what about calls
that use F77_FUNC directly instead of using F77_XFCN?  I think some
calls to BLAS functions use F77_FUNC instead of F77_XFCN because they
don't need to set up the setjmp/longjmp error recovery.

jwe

[c.-2]

On 29 Jan 2013, at 04:33, John W. Eaton <[hidden email]> wrote:

> On 28-Jan-2013, Jordi Gutiérrez Hermoso wrote:
>
> | On 28 January 2013 16:29, c. <[hidden email]> wrote:
> | >
> | > On 28 Jan 2013, at 18:03, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
> | >
> | >> In fact, I would welcome a patch to conditionally enable at compile
> | >> time this debugging output [for displaying which F77 functions get
> | >> called].
> | >
> | > Well, here's the patch.
> | [snip]
> | > feel free to push the changeset if you like it or ignore it if you
> | > don't
> |
> | I like it, except I wouldn't use a warning to display this. Perhaps
> | just octave_stdout? It does have the convenience of being easier to
> | turn on and off with the usual warning mechanism, though.
>
> I'm not completely opposed to this idea, but I think it is a little
> odd to target all F77 functions.  The proposed change will show more
> than just calls to BLAS and LAPACK functions and will stop working if
> we change Octave to use a C interface to the BLAS and LAPACK instead
> of the current Fortran interface.  Also, in many cases, we call the
> same routine twice (once to get the work array dimensions and once to
> perform the calculation) so the output will be somewhat more verbose
> than necessary.  Finally, I think it will be hard to follow exactly
> what is happening for complicated expressions (you'll get a lot of
> output without knowing precisely which subexpression is responsible
> for each call) and you'll need to be very familiar with the BLAS and
> LAPACK libraries to understand the output.  I know it would be more
> work to implement, but I think it would be better to have output that
> looks something like this:
>
>  calling DSYRK ("U", "T", 10, 10, 1.0, A(10,10), 10, 0.0, c, 10)
>  called from:
>    foo at line 123, column 45
>    bar at line 678, column 9
>
> and to limit this to selected BLAS or LAPACK functions, not every
> function call that uses the F77_XFCN macro.
>
> If you do want to go with the simpler change, then what about calls
> that use F77_FUNC directly instead of using F77_XFCN?  I think some
> calls to BLAS functions use F77_FUNC instead of F77_XFCN because they
> don't need to set up the setjmp/longjmp error recovery.
>
> jwe

The two attached changesets are all I can do to comply with your suggestions at this time.
The first one adds an option to make invocation of F77 functions more verbose, but does not overwrite
the default macros. The second one, which contains changes EIG.cc, is an example of how these macros
can be used to modify "selected BLAS or LAPACK functions" only, the same changes should be manually applied
to all calls that are considered relevant.

Although I understand the usefulness of being able to know what BLAS or LAPACK calls are used under the
hood by Octave when performing a specific task, I do not plan to use this functionality myself any time
soon. So I'll leave it to the OP (or to Jordi if he is so inclined) to select the appropriate locations where
the verbose macros could be used.

HTH,
c.