Mentions légales du service

Skip to content

New testing/timing structure

This PR aims at rewriting the timing/testing directories in order to simplify the set of drivers we have to test the functionalities of the library, and extend the coverage of the testing performed by the CI at every merge.

Default of the previous version:

  • Testings:
    • A single testing was covering many functionalities all in once. It was good, but was also limiting the coverage as it was not testing all unmqr/unmlq applications for example, but only the ones used in solving a linear system.
    • Parameters where fixed in the command line and must be given in a fixed order
    • The lapack interface was tested, and could not allow us to test the distributed interface
    • Many checking functions were duplicated in multiple test files
    • Could not allow to time the functionalities for performance analysis
  • Timings:
    • Limited coverage of the functionnalities
    • Not all timings were including testing capabilities despite its availability in the testing directory
    • Could not time all routines independently

The new structure tries to solve all, or a large set of these defaults:

  • Parameters:
    • Options are supported through getopt to allow any order.
    • Add the capability to pass options by files
    • The set of test performed is defined by the cartesian product of the parameters given as input
    • Easy to add options by adding it to a table of input,output parameters
    • Choice between human readable and csv output to ease analysis of results
    • Each parameter can be given as a single value, a range, or a list of values
  • Timing/testing:
    • Each routine is tested/timed in the same file. We are sure that what we time is correct.
    • Test the tile interface, thus we can test/time distributed functions easily
    • Each function is tested/timed independently in a file of its name
    • Checking functionalities have been merged to avoid code replication

Drawback: The lapack interface is not tested anymore. However, it is planed to keep the old fortran testing to put it back in a future, in order to test the old lapack interface, and eventually provide a lapack compatible interface, and having the lapack testing as a submodule.

Edited by Mathieu Faverge

Merge request reports