The E-graph extraction problem is NP-complete
effect.systems
effect.systems
Decent chance you can hack 'optimal' out in a reasonable timeframe if you run that heuristic first and then prune the search space to discard any solution that would be worse than said first guess.
I'm certainly not convinced by the argument that optimal egraph is equivalent to the minimum set cover problem and thus in NP. I can believe that egraph extraction can be modelled as minimum set cover, but there's a lot of additional structure in the egraph which I suspect takes us out of the general case.
By analogy, it is known that register allocation is NP complete because it's graph colouring. Despite that, register allocation on a chordal graph can be done in linear time, and SSA form gives you a chordal graph. Being a specific instance of a hard problem matters.
Are you like actually misunderstanding or are you trying to say something else - egraph is in np because it's equivalent to ilp and it's complete because you can reduce set cover to it not the other way around (the reduction always goes to the problem not from the problem in a completeness proof).
>Despite that, register allocation on a chordal graph can be done in linear time, and SSA form gives you a chordal graph.
This isn't saying much since SSA construction (phi elimination) isn't linear.
Start with a set cover problem, NP. OK. Translate it mechanically to an e-graph in polynomial time, sure, that instance of the e-graph is still unsolvable in polynomial time. It doesn't follow that all instances of e-graphs are unsolvable in polynomial time, only that some aren't.
Your e-graph is really heavily constrained by the ISA and optionally by the ABI. It's also constrained by the code it was created from which will tend to have its own constraints. Constraints can lead to faster solutions.
SSA construction is putting phi's in, if you're using them instead of block arguments. Destruction is taking phis out. Whether that's linear time or polynomial or non-polynomial depends on how optimal a job of eliding copies you choose to do.
>It doesn't follow that all instances of e-graphs are unsolvable in polynomial time, only that some aren't.
Yes and hardness results are about proving lower bounds on worst case complexity not best case or sometimes case or whatever-you-chose-as-meaningful case.
Specifically, e-graphs are used with respect to an ISA from which the cost model is derived. My intuition is that this constrains the structure sufficiently that polynomial solutions can be found. Probably involving a partial order calculated ahead of time.
For me, whether the result in the opening post is applicable to uses of e-graphs in compilers has a strong influence over whether I need to worry about it or not. I'm on the fence about e-graphs as a model. If rolling one into production means I'll occasionally hit exponential increases in running time as heuristics fall over, that's an argument against. If those cliffs are unreachable for a given ISA, they don't matter.
By rice's theorem, for any ISA that has a jmp or mov, there is no way to know/prove/predict this. So you're still not saying anything useful.
Also: if you are okay with heuristics that aren't guaranteed to output the optimal answer the whole point is moot
Languages tend to be designed with comprehensibility in mind - so the thoroughly unjustifiable hunch that I'm having is that the vast majority of the extreme complexity possibilities are for languages that no sane human would design, let alone actually work with.
I am not sure I understand your comment on language structure. E-graphs are used to reason automatically about equivalence of (PL or) math expressions, there is quite a lot of possible combinations of assembly opcodes or other bytecodes and do not humans interact with them directly but compilers and formal tools have to.
(Edit: typo, meant humans do not interact with bytecode directly... Usually)
> do not humans interact with them directly but compilers...
So compiler programmers deal with them and humans designed them to be dealt with by the people that write compilers.
There's a major selection bias active here - the e-graph is a reflection of the language (and perhaps the target ISA) and its complexities.
Since at each level it's likely to have been designed for comprehensibility it seems to me unlikely that any given example will be buried in the intractable heart of NP.
But as I said, it's a hunch.
First of all, I had no idea what an E-graph was, so I had to search for that myself.
Then the post presents the problem itself, without explaining a practical situation in which you’d need to compute/solve this. Would this be used by a compiler to come up with an optional execution strategy? Or an interpreter to evaluate terms?
It talks about the use of a cost function, but to me it’s not clear where it comes from, and what the cost represents. Would that be CPU cycles? Memory use?
I decide to do a Google search for “E-graph extraction problem”, but apart from the blog post itself, I get no meaningful results. I feel lost.
my cynical eye sees this as an over-eager grad student rushing out his/her discovery onto hacker news. Next thing you know, an FPTAS for it may rear its ugly head.
Any discovery is a step forward (whether it is news or not)..