TensorOps test simplification
@corbett5 is already working on this.
Since Dec 11, 2020.
Assessment
This issue has not been assessed yet.
Description
The current tensorOps tests are to their benefit
- Exhaustive.
and to their detriment
- Complicated. They involve heavy usage of macros and are spread across multiple source files.
- Slow to compile, maybe a minute or two with NVCC and super long with Intel or XL (not that I really care about those).
This is proving to be the part of LvArray that is touched most frequently by other developers and as such I would like it to be easy to add tests. If there is an existing test that is similar to the new function copying works fairly well, but due the unique file structure it can be hard to find a specific tests, and if there isn't a similar test writing one from scratch is non-trivial.
Currently much of the complexity arises from my desire to test all of the template functions with many of the possible argument permutations. For example to test the trivial copy I test all nine permutations of ArraySlice< T, 1, 0 >, ArraySlice< T, 1 -1 > and T[ N ]. This test is then instantiated for three different combinations of T and N, and another 3 when using CUDA. Just looking at the code for copy it is pretty obvious that it is correct so this seems like overkill, the purpose of the tests is as much to verify that things compile as to verify runtime correctness. The template explosion leads to long compile times and I've spread the tests across multiple translation units to make it faster.
I'm starting to think that it might be worth decreasing the test coverage if it could significantly decrease the barriers to entry. What has been your experience adding tests, was there anything in particular that took some work to figure out?
Tagging people who have added tests:
@klevzoff @francoishamon @CusiniM @rrsettgast
- Dominant language
- C++
- Stars
- 49
- Forks
- 9
- Avg merge
- 5d 15h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from GEOS-DEV/LvArray
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
GPU stacktrace Open
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
All issues in GEOS-DEV/LvArray
Similar issues
-
Website Doc Typo Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
automated-analysis bug memory-safety
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100