Stream: t-compiler

Topic: queries / futures


Jake Goulding (Nov 16 2018 at 15:59, on Zulip):

Based on the talk of queries over in the steering meeting, I'm curious if:

1. Could the compiler's query system be written in terms of futures
2. Would there be any benefit to it, if so?

nagisa (Nov 16 2018 at 15:59, on Zulip):

1. Could the compiler's query system be written in terms of futures

Dubious, almost no work compiler does is asynchronous.

mw (Nov 16 2018 at 16:00, on Zulip):

yeah, the compiler would have to have something useful to do while it's waiting for a future to finish.

nagisa (Nov 16 2018 at 16:10, on Zulip):

@nikomatsakis / @eddyb "smaller" queries were mentioned during the meeting

nagisa (Nov 16 2018 at 16:10, on Zulip):

can you elaborate on what was meant by “smaller”?

eddyb (Nov 16 2018 at 16:12, on Zulip):

finer-grained, I assume?

mw (Nov 16 2018 at 16:12, on Zulip):

yes, esp. since we want to make at least some of them "larger"

mw (Nov 16 2018 at 16:12, on Zulip):

https://internals.rust-lang.org/t/next-steps-for-reducing-overall-compilation-time/8429/4?u=michaelwoerister

nagisa (Nov 16 2018 at 16:13, on Zulip):

So, for example I’m making a query currently to collect #[optimize] attributes from all the items in a crate, which essentially ends up touching all the items in a crate.

nagisa (Nov 16 2018 at 16:13, on Zulip):

how would one make it more fine-grained?

nagisa (Nov 16 2018 at 16:14, on Zulip):

I can’t see us being able to avoid such queries any way…

mw (Nov 16 2018 at 16:24, on Zulip):

what exactly is the purpose of this query?

oli (Nov 16 2018 at 16:37, on Zulip):

Don't we usually have a query to get such info for just one item and then have the collector run that query on all items yo cache the result if the result can only be computed in the current query

mw (Nov 16 2018 at 16:40, on Zulip):

@Oli yes, that makes sense if each individual query is expensive

nikomatsakis (Nov 16 2018 at 19:38, on Zulip):

@Jake Goulding I think the main reason to do that would be as part of parallel execution — if you have two threads that both want to compute the type-check of X at the same time, you presently have to block (or else duplicate the work). I don't think it's worthwhile though.

nikomatsakis (Nov 16 2018 at 19:39, on Zulip):

but once we have a working parallel compilation implementation this is the kind of thing we can explore

nikomatsakis (Nov 16 2018 at 19:39, on Zulip):

(that is, trying to get some data on how much these sorts of conflicts arise in practice)

mw (Nov 16 2018 at 22:46, on Zulip):

parallel queries already provides asynchronous execution of queries -- I guess it wouldn't be too hard to provide a futures-like api in addition to the blocking one. But I also think that the rayon-like par_iter() api covers 95% of the use-cases pretty well.

Last update: Nov 20 2019 at 01:45UTC