Prune once before extraction instead of every eqsat iteration

[paulzzy]

• Prune once before extraction instead of every eqsat iteration
• Restrict exponent in pow constant folding

Runtime performance is improved by 6-8%, from ~70 minutes for a full benchmark run on main to ~65 minutes with this PR. Accuracy changes are a tossup (some worse, some better).

In this context, "pruning" means removing e-nodes with children if its e-class contains at least one leaf e-node.

[pavpanchekha]

Ok, if need be I'd be willing to merge this as is but I think it would be nicer if we could remove the old pruning code, which I think would mean changing the lib.rs code to not use is_some and instead just scan the whole e-class for leaf nodes. Do you think that's reasonable? It'd let us delete some code (good) and I don't think we'll want to keep pruning around once we get rid of it.

[paulzzy]

I'll remove the old pruning code! I agree, I don't think it needs to be configurable.

Regarding the eclass.data.is_some(), that's actually necessary because only constant folded e-nodes can be safely pruned. Removing that conditional results in a broken e-graph.

[pavpanchekha]

I didn't mean removing that conditional on its own, but I think we can prune all enodes for classes with any leaf node, right? At least I think any variable should also be good?

[paulzzy]

Awesome, looks like even more performance gains with your pruning approach (up to 9%).

I'm surprised it worked! I thought that pruning e-classes with at least one e-node would result in an e-graph that only contains the shortest expressions. Since the optimal floating point expression is sometimes longer than the original expression, I thought accuracy would go down. Are e-graphs used differently than I expected?

[pavpanchekha]

Yes, though it also makes low-accuracy results worse. I’d love to investigate, but willing to merge on balance without that.

Unrelated, but strongly encourage thinking about speedups in absolute, not relative, amounts. 5min not 9%. Otherwise easy to confuse self with iterated improvements, like Amdahl law.

[pavpanchekha]

My plan:

1. Review code
2. If time, figure out why one benchmark (Rump from Stadherr) has different input accuracy (shouldn’t happen)
3. If time, figure out what’s up with long tail

[pavpanchekha]

Code looks good (though please fix comment). My plan remains as above—I'll see if I find time to investigate the things I want to, but if I don't in a few days I'll just tell you to merge it.

[pavpanchekha]

Update: I figured out why Rump from Stadherr changes input accuracy; it's a Herbie bug but not related to this PR, so that's no longer a blocker.

I did notice that the accuracy is now worse than main, something like 40% lower. Do you think this is just random variation, or is it changed from the earlier pruning approach? Because if somehow we're now pruning too much we can change it back. Sorry for that back-and-forth! If you're getting frustrated with the process and just want the damn thing merged, I'm also willing to merge this as is and delay experiments with different pruning to another PR.

[paulzzy]

Thank you for the thorough investigation! I’m also willing to be thorough. :)

I did notice that the accuracy is now worse than main, something like 40% lower

Are you referring to Rump from Stadherr specifically or the overall benchmark suite? I can experiment with reinstating the constant fold pruning and trying different seeds.

[pavpanchekha]

Overall