On 10/20/2021 3:27 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 1:00 AM Jeff Law <jeffreya...@gmail.com> wrote:
On 10/18/2021 8:03 AM, Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with reducing the total number of threading
passes, and I'd like to see if there's consensus/stomach for altering
the pipeline. Note, that the goal is to remove forward threader
clients,
not the other way around. So, we should prefer to remove a VRP threader
instance over a *.thread one immediately before VRP.
After some playing, it looks like if we enable fully-resolving mode in
the *.thread passes immediately preceeding VRP, we can remove the VRP
threading passes altogether, thus removing 2 threading passes (and
forward threading passes at that!).
It occurs to me that we could also remove the threading before VRP
passes, and enable a fully-resolving backward threader after VRP. I
haven't played with this scenario, but it should be just as good.
That being said, I don't know the intricacies of why we had both pre
and post VRP threading passes, and if one is ideally better than the
other.
The only post-VRP threading pass that (in my mind) makes sense is the
one sitting between VRP and DOM and it should replace the DOM based
threader.
Yes, that's the goal, but it won't happen on this release because of
floats. The DOM threader uses the const/avails machinery to thread
conditionals involving floats, something the path solver can't do
because it depends on gori/ranger. Adding floats to ranger is
probably our #1 task for the next cycle.
Now before Andrew gets clever, the relation oracle is technically type
agnostic, so it could theoretically be possible to use it in the DOM
threader and replace all the const/avails stuff. But I'd like to go
on vacation at some point ;-).
Correct. I just wanted to make it clear that as the backwards threader
improves I see less and less of a need to run as many threader passes.
For VRP1 -> DOM2, I could see removing the threading path from DOM2 and
having a backwards threader between VRP1 and DOM2. I don't see
significant value in having a threading pass of any sort after VRP2 as
the vast majority of things are handled by then.
Jeff
