Open alexfikl opened 2 years ago
@kaushikcfd Is this worth pursuing given that compile times are suffering because of expression traversal complexity in pymbolic?
@kaushikcfd Is this worth pursuing given that compile times are suffering because of expression traversal complexity in pymbolic?
For what it's worth, the loopy
branch is up to date and passing tests locally, so it shouldn't be too hard to clean this up.
Is this worth pursuing given that compile times are suffering because of expression traversal complexity in pymbolic?
I think this is useful. IIUC, this PR quite significantly brings down the complexity of the expression comparison. If the overheads of this approach (creating a new mapper for every comparison) are under-control, I would love to get rid of hacks such as: https://github.com/kaushikcfd/pymbolic/blob/a697d47cd53e9902abc49f98d67921b466c992c2/pymbolic/mapper/__init__.py#L213.
However, I wonder how the loopy CI failures could be fixed? By creating a derived version of every pymbolic expression type in loopy so that they can use loopy-specific EqualityMapper?
However, I wonder how the loopy CI failures could be fixed? By creating a derived version of every pymbolic expression type in loopy so that they can use loopy-specific EqualityMapper?
It should work with the modified branches. I imagine it needs some work in ci-support.sh
to clone the correct repo and branch (instead of hardcoding to inducer/loopy@main
).
Oops had missed the branch in the description. I think those will work fine. Thanks!
I would love to get rid of hacks such as:
Whoa. I had missed that during review. That is pretty gross.
I need to do some measuring.
Added an
EqualityMapper
similar to the one in inducer/pytato#166.This seems a bit slower than the current version (benchmarked against inducer/pytential#121): it went from 5.3s-ish to 6.6s-ish.
fail-fast
from downstream CIFixes #73.