Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc for running tests #196

Closed
loveshack opened this issue Dec 19, 2017 · 2 comments
Closed

doc for running tests #196

loveshack opened this issue Dec 19, 2017 · 2 comments
Assignees
Milestone

Comments

@loveshack
Copy link

It would be useful to document running tests, which is relevant for packaging.

I tried "make test" for basic sanity, and was surprised it rebuilt the
libraries which were already built (using the same flags in both cases). It
also failed to link, missing openmp, which wasn't specified in the build
step of the Fedora package.

I haven't spent much time looking at it as I'm not sure what's intended, so
information on the recommended procedure would be helpful. (I realize I
should be able to rely on it working, but packages are supposed to run some
test if it's available.)

@hfp hfp self-assigned this Dec 19, 2017
@hfp
Copy link
Collaborator

hfp commented Dec 20, 2017

I acknowledge this use case (package test), and I will document/implement it with v1.9. What about make tests? As you discovered already, it's "tests" (and not "test", which is something else). Also, you need to pass the exact same options as used for building the library (key-value pairs). For example, if your main case is make STATIC=0 and you want to test this build, you need to run make STATIC=0 tests. Regarding the surpising rebuild, LIBXSMM detects if a rebuild is needed based on the relavant state of "make" (key-value pairs passed with make). If you omit any key-value pair when running the "test" target, you will encounter a rebuild (and test something else).

For the package, I suggest to use only make or make STATIC=0, and to omit any further adjustments (if possible). In particular OMP=1 does not need to be set, and also no SSE or AVX adjustments. The build uses SSE4.2 code by default, which runs nowadays everywhere (or this library makes little sense). If it's crippled below SSE4.2 (CRC32 instruction), additional CPUID-based dispatch is used and some overhead is incurred even in the fast-path. I put quite some effort into drawing this baseline requirement, and it's an acknowledgement of what's needed for general packages.

@hfp
Copy link
Collaborator

hfp commented Feb 2, 2018

I have improved the main documentation to explain the build system: "each set of given key-value pairs represents a different build (and test)", which sheds some light on what happens when running make tests (which is roughly equivalent to cd tests; make; ./test.sh). There is also a new Wiki page documenting Basic Tests and Test Suites: https://github.com/hfp/libxsmm/wiki/Validation. However, the latter is likely some overkill for what was asked for.

@hfp hfp closed this as completed Feb 2, 2018
@hfp hfp added this to the 1.8.3 milestone Feb 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants