support aborting on cache miss

[matthiasdiener]

What do you think @inducer? This would not only make debugging cache misses easier, it could also be used to automate determinism and more general caching tests (by setting LOOPY_ABORT_ON_CACHE_MISS to something trueish, and rerunning the test).

TODO:

• add for other cache loads?

Please squash

[inducer]

I'm not wildly opposed, but I feel that it's also easy to just hack a 1/0 into that code path when needed. And for automated determinism tests, there are probably simpler approaches than to ask the codegen cache.

Also, "abort on cache miss" sounds like it would include all caches, but this applies to only one of many caches in loopy.

[matthiasdiener]

@inducer If possible, I would like to revisit a way to make cache misses automatically testable.

I'm not wildly opposed, but I feel that it's also easy to just hack a 1/0 into that code path when needed. And for automated determinism tests, there are probably simpler approaches than to ask the codegen cache.

Do you have a suggestion on another approach? I thought of perhaps adding a way for persistent_dict itself to abort on a miss, but not sure if that would be better.

[inducer]

Do you have a suggestion on another approach?

Um, "hack a 1/0 into that code path when needed." 😁

[matthiasdiener]

Do you have a suggestion on another approach?

Um, "hack a 1/0 into that code path when needed." 😁

That doesn't work for automated testing ;-)

[inducer]

Ah, fair. 🤷 Let's do this then?

[inducer]

Maybe add a comment to explain that the env var is for automated tests?

[matthiasdiener]

@inducer do you remember what the purpose of this pytest_twice CI check was/is? Is it just about seeing the time difference between the first pytest run and the second run?

[inducer]

No, it's supposed to test that things still work with data pulled out of a cache, since the first round of tests runs on a cold cache by default.

[matthiasdiener]

Is it expected that running pytest like this will lead to cache misses on the second run (demonstrated by the CI in this PR)? I've tried to go back to earlier loopy versions, and it seems like these cache misses are not caused by recent changes.

[inducer]

Huh, I would not expect there to be cache misses on the second go.

[matthiasdiener]

I suspect code like this (from test_c_execution.py) is responsible for the cache misses:

def __get_kernel(order="C"):
    indices = ["i", "j", "k"]
    sizes = tuple(np.random.randint(1, 11, size=len(indices)))
    # ...

Would you prefer me to make these sizes constant across runs, or should we just ignore the cache miss?

[inducer]

Setting a seed (and converting to the new-style numpy RNG interface) seems like the way to go.

[matthiasdiener]

Considering the multitude of issues encountered, it is probably not realistic to enable this in CI for the near future. I'll disable the export for now.