You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DeadlineExceeded failures in test_eye/test_linspace #214
two test new failures consistently occur (after updating from f82c7bc to recent tip of main, i.e. 9d7777b), e.g.:
FAILED array_api_tests/test_creation_functions.py::test_eye - hypothesis.errors.DeadlineExceeded: Test took 1470.80ms, which exceeds the deadline of 800.00ms
FAILED array_api_tests/test_creation_functions.py::test_linspace - hypothesis.errors.DeadlineExceeded: Test took 864.40ms, which exceeds the deadline of 800.00ms
Here is my understanding of what happens.
Hypothesis would generate a sufficiently large array, i.e. eye(47, 100) but testing of the output correctness is is done one element at the time (suboptimal usage for offloading libraries as it triggers 4700 submissions of small kernels) and this testing would take much longer than the creation of the array itself:
In [7]: import dpctl, dpctl.tensor as dpt
In [8]: %time eye_m = dpt.eye(47,100)
CPU times: user 3.23 ms, sys: 0 ns, total: 3.23 ms
Wall time: 2.76 ms
In [9]: %time all(eye_m[i, j] == (1 if i == j else 0) for i in range(eye_m.shape[0]) for j in range(eye_m.shape[1]))
CPU times: user 6.68 s, sys: 1.98 s, total: 8.67 s
Wall time: 2.09 s
Out[9]: True
The remedy would be to restrict the maximal dimension size.
Just to say, what we (i.e. me) intend to do after resolving #221 is to review the test suites method of array comparison, because yes it's awfully slow right now.
Historical reasons (signed zero/NaN comparisons, masking being optional, and a mistrust of adopter's implementations of comparison functions) meant we've just iterated over arrays and casted elements one-by-one. But we probably can use vectorization everywhere at this point, with some clever use of xp.where, and some more trust/sanity-checking of adopter's own comparison functions.
I had trouble getting dpctl to work locally, although will have a serious go at it down the line as obviously it'll be useful. IntelPython/dpctl#1619 did help.
Activity
[-]DeadlineExceeded failures in test_eye/linspace[/-][+]DeadlineExceeded failures in test_eye/test_linspace[/+]oleksandr-pavlyk commentedon Dec 12, 2023
This is the change I applied locally:
and it has helped with the timeout. I think a similar change needs to be applied to
pytest_helpers.assert_array_elements.If this looks OK, I will open a PR
honno commentedon Jan 16, 2024
Just to say, what we (i.e. me) intend to do after resolving #221 is to review the test suites method of array comparison, because yes it's awfully slow right now.
Historical reasons (signed zero/NaN comparisons, masking being optional, and a mistrust of adopter's implementations of comparison functions) meant we've just iterated over arrays and casted elements one-by-one. But we probably can use vectorization everywhere at this point, with some clever use of
xp.where, and some more trust/sanity-checking of adopter's own comparison functions.Related discussions:
honno commentedon Apr 16, 2024
@oleksandr-pavlyk I wonder if this is fixed already? #236 and #246 might of solved this already.
I had trouble getting
dpctlto work locally, although will have a serious go at it down the line as obviously it'll be useful. IntelPython/dpctl#1619 did help.