You're probably thinking of https://github.com/simonlindholm/decomp-permuter, which is used across many more decomp projects (and can do a lot more than swap lines). It's a huge help, but it's by no means enough for all regalloc differences; there's lots of stuff it cannot do.
I see that now… why did they check it in? One of the whole points of this approach is that that assembler should be trivial to re-derive by the end user since it’s just the original program listing. Some of the Xbox 360 recomp projects like https://github.com/mchughalex/skate3recomp offer a better example of how this pattern can be achieved without distributing the binary at any intermediate level.
They are designed by different teams and have different ways of doing math. You could just as easily say “why are the efficiency cores wasting an extra cycle for each multiplication doing fixups of an uncommon case”.
> For example, one could analyze _actual_ distributions or whatever (instead of assuming uniform)
Postgres keeps histograms (including N most common values) for all columns; it does not blindly assume uniform distributions. (Presumably an LLM would have access to the same histograms.)
GEQO is not to get a better plan than the traditional optimizer, it is to be able to get a plan at all when the query is large. And it's widely known for creating poor plans.
Yes, but it's exactly the kind of hybrid between a regular planner and something generative (writ broadly) that they were asking about. Practically speaking if you're hitting the GEQO you've already failed as a query writer unless it's a purely OLAP on a dedicated beefy machine.
I think calling GEQO generative is a bit of a stretch; it's just a different way of searching through the same space with the same cost model. More or less devolving to “let's take a bunch of randomized join orders and see which one is best” :-)
And yes, large joins is definitely for OLAP use. If you have 20-way joins for OLTP, you're either crazy or you're using an ORM.
You create formulas to estimate the cost of running a given query plan. Use statistics collected about the tables (e.g. how many rows) to try to be accurate. The topic is "Cost Based Optimization".
If you have formulas that actually match reality, what do you need the LLM for? An optimizer is perfectly capable of finding the optimal plan if it has a perfect estimator. In fact, if you could only estimate the number of rows in each subplan perfectly, you have as good as solved the problem already.
> If you have formulas that actually match reality, what do you need the LLM for?
Because one could be in that state where they are trying to use a tech they know preciously little about to solve a problem they know nothing about.
This reminds me of a request we got from our "AI Department": if you build us a proper shares market simulator, we will build you an awesome agent that can trade shares. They seemed quite confused when I pointed out that if we could build such a simulator, we wouldn't need them anymore.
> If you have formulas that actually match reality, what do you need the LLM for?
That's the key question.
I think LLMs allow people with no context or background or know-how to dive into projects and see some results being presented to them, but they don't have the context or skillset to tell what they see before them.
This paves the way to people laying grand claims about achievements because of LLMs. Their claim is that LLMs know best primarily because LLMs knew more than them, not that the output is good or desirable.
This is how the built in planner works already. It generates all possible plans and picks the one with the lowest cost. But calculating the cost is based on statistics and models, and these are wrong. Usually useful, but always wrong.
There are papers and Postgres projects that attempt this kind of learning-based optimization, with some success. None are in widespread use. (One part, but certainly not the entirety, of the problem is that it's not just A/B, it's an exponential number of options that all could seem close to each other.)
Only in the worst case when the plans are equivalent: If one plan is significantly faster, then it'll finish first, and the loser can get canceled before it finishes.
Good and bad plans can have orders of magnitude performance difference. The bad one can easily do enough damage cutting the performance in half before it is canceled.
People kept asking if they could pay for AnandTech, and they said “we'll think about it” for years until they shut down instead because it was financially unsustainable.
reply