bugGNU Octave - Bugs: bug #54183, Cache NaN/Inf status of matrix for...

 
 

bug #54183: Cache NaN/Inf status of matrix for performance?

Submitted by:  Rik <rik5>
Submitted on:  Mon 25 Jun 2018 06:11:33 PM UTC  
 
Category:  Performance Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 25 Jun 2018 07:16:03 PM UTC, comment #1:

Could we combine both?

In some cases, I think we already check the matrix type for things like symmetry. So if we are doing that anyway, we could also check for Inf or NaN values.

In other cases, we might only want to check the matrix type if it is already set (rather than computing anything prior to a BLAS operation) and then try the BLAS operation. If it fails, then try to determine why, or possibly do the more expensive checks for matrix type and NaN or Inf elements. At that point, we can set the return value appropriately and also modify the matrix type info of the original matrix.

I should also note that one thing I don't like about the current matrix type calculation and caching is that it relies on mutable data and that can cause unpredictable behavior if the compiler optimizes based on assumptions of constness. So we may need to be careful about how these checks are handled.

John W. Eaton <jwe>
Project Administrator
Mon 25 Jun 2018 06:11:33 PM UTC, original submission:

Low-level Octave code in liboctave often calculates the 1-norm of a matrix before calling BLAS/LAPACK routines. This was originally done to prevent segfaults and other unhandled exceptions in the external library code.

However, this is obviously a lot of work, even for the 1-norm. Now that bug #39000 has been resolved for Windows (XERBLA handler override for external BLAS libraries) there is no longer a pressing need to inspect the matrix so thoroughly before handing it over to the library.

Architecturally, it would be useful to consider the locations in liboctave where we calculate the 1-norm and determine if they could be removed, and instead catch any error from the external library and modify the return value as necessary. In pseudocode

This has the advantage of only bothering to inspect the matrix if there is a problem with the calculation.

Alternatively, there is already a caching system in place for Octave matrices that records any special properties abouth them (diagonal, banded, symmetric, etc.). This caching system could be extended so that any NaN or Inf status of a matrix was calculated only once.

The first solution is preferrable, since most of the time there is no reason to check a matrix as most will be valid. But at least the second solution would restrict the calculation to once per matrix.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-25 rik5 Carbon-Copy- => Added jwe

    Back to the top


    Powered by Savane 3.3