Stream: t-compiler/wg-mir-opt

Topic: miri performance


Alexander Regueiro (Sep 21 2019 at 01:57, on Zulip):

Now that I'm getting close to publishing my REPL project (based on miri of course), I'm wondering what we can do to speed up its performance if we only care about execution and not using miri as a validator / bug-finder. I'm thinking:
a) -Zmir-opt-level=3 (this is default, so just remove the =0 from the args that miri sets?)
b) remove assertions in lots of places
c) other things?

oli (Sep 21 2019 at 12:15, on Zulip):

removing asserts and similar things only makes sense after benchmarking

oli (Sep 21 2019 at 12:15, on Zulip):

but in general, you won't be able to do much, miri just does a lot of work

oli (Sep 21 2019 at 12:16, on Zulip):

you can disable validation for the repl

oli (Sep 21 2019 at 12:16, on Zulip):

that will give you a 2x boost

Alexander Regueiro (Sep 21 2019 at 14:30, on Zulip):

@oli okay, fair enough. will have a look, thanks

Alexander Regueiro (Sep 21 2019 at 17:03, on Zulip):

@oli BTW, I'm right in saying that mir-opt-level=0 means no optimisation?

Alexander Regueiro (Sep 21 2019 at 17:04, on Zulip):

i.e., point a abovee

gnzlbg (Sep 22 2019 at 10:57, on Zulip):

a 2x boost probably still means something like 500x slower than a release build

Alexander Regueiro (Sep 22 2019 at 19:11, on Zulip):

yeah, though if we can work towards a 100x slowdown, that would be decent I think (if you have any ideas, let me know)

Alexander Regueiro (Sep 22 2019 at 19:12, on Zulip):

eventually, would be nice to do what the ghci does and run extern crates as native code.

Alexander Regueiro (Sep 22 2019 at 19:12, on Zulip):

@gnzlbg

gnzlbg (Sep 22 2019 at 19:32, on Zulip):

not really, what would have a big impact is moving towards jitting the code that's used in the repl

gnzlbg (Sep 22 2019 at 19:32, on Zulip):

but the hardware your repl runs on is actually miri

Alexander Regueiro (Sep 23 2019 at 01:32, on Zulip):

@gnzlbg I don't get how you could JIT it, given it's interpreted...

Alexander Regueiro (Sep 23 2019 at 01:33, on Zulip):

unless I misunderstand you entirely...

gnzlbg (Sep 23 2019 at 05:59, on Zulip):

no you didn't, because the repl is based on miri, you are limited to the interpreter

gnzlbg (Sep 23 2019 at 06:01, on Zulip):

you'd need to bypass the interpreter to make it faster

gnzlbg (Sep 23 2019 at 06:04, on Zulip):

If the only thing the user is allowed to enter in the REPL is const fns, one could try to treat them all as intrinsics

gnzlbg (Sep 23 2019 at 06:05, on Zulip):

compiling them to machine code, running them, and then passing their result to the interpreter

gnzlbg (Sep 23 2019 at 06:05, on Zulip):

for anything more complicated I don't see how it could work

Alexander Regueiro (Sep 23 2019 at 21:48, on Zulip):

hmm yeah

Alexander Regueiro (Sep 23 2019 at 21:48, on Zulip):

seems no point even using miri if we go that route though

Alexander Regueiro (Sep 23 2019 at 21:48, on Zulip):

this should suffice for now

Alexander Regueiro (Sep 29 2019 at 01:01, on Zulip):

@oli Okay, I went through the cosmetic changes and did my best to only keep the ones that were nearby to the functionality changes. Hopefully that conforms to the policy better now, and doesn't bother you. Please note that I'm mainly just bad at judging these things (I look at the matter through a very different lens to you), and time may have led me to slip back more into old habits — I am not intentionally trying to piss people off, but you're entitled to your own judgement anyway... Well, I'm going to presume this matter is now basically resolved, and collapse both of our comments simply to avoid noise and people seeing contention which is really only distracting from the actual PR at this point. That said, if you'd like to highlight in brief anything I missed, feel free to point that out to me there or here. Thanks.

oli (Sep 30 2019 at 06:35, on Zulip):

Thanks, looks great now. I just tried to do a normal review, though the github interface just ignores me adding comments to that PR. I'll leave a review here then I guess

oli (Sep 30 2019 at 06:36, on Zulip):

You added an interp_tag field to ast and hir Local, is anything speaking against just making it a regular rustc attribute?

oli (Sep 30 2019 at 06:38, on Zulip):

wrt interp_user_fn, why does this need to be part of the compiler-API? I mean only the query, adding the attribute is obviously fine. Couldn't you just run the query code in your interpreter without having to add any additional logic to rustc?

oli (Sep 30 2019 at 06:39, on Zulip):

the interp_mode compiler flag seems to be entirely unused, what do you use it for?

oli (Sep 30 2019 at 06:52, on Zulip):

the doc comment change on stderr is odd, you're mentioning true, but it's not a boolean

oli (Sep 30 2019 at 07:00, on Zulip):

Can you explain the interp_user_fn parsing scheme that you implemented? I'm not sure how the repl is going to use it

Alexander Regueiro (Sep 30 2019 at 15:13, on Zulip):

Weird. Anyway, review here is fine.

Alexander Regueiro (Sep 30 2019 at 15:16, on Zulip):

You added an interp_tag field to ast and hir Local, is anything speaking against just making it a regular rustc attribute?

Mainly convenience. Also, semantically it felt more correct to have it as an inherent property of the Local, since diagnostics for borrowck make use of it. (You can see this in my personal branch for all the changes, though I admit it's a huge commit.)

oli (Sep 30 2019 at 15:17, on Zulip):

Hmm

oli (Sep 30 2019 at 15:17, on Zulip):

In that case I think it would really be best to use an attribute

oli (Sep 30 2019 at 15:17, on Zulip):

you can create a convenience wrapper out of tree for extracting your properties from attributes so you don't have much usability regression (calling a function instead of accessing a field)

Alexander Regueiro (Sep 30 2019 at 15:18, on Zulip):

wrt interp_user_fn, why does this need to be part of the compiler-API? I mean only the query, adding the attribute is obviously fine. Couldn't you just run the query code in your interpreter without having to add any additional logic to rustc?

it could be except that ty pretty-printing makes use of it in two places (in a PR to come) to change the way tys are pretty-printed in diagnostics and generally

Alexander Regueiro (Sep 30 2019 at 15:18, on Zulip):

the doc comment change on stderr is odd, you're mentioning true, but it's not a boolean

I'll have a look. Could be a mistake on my part.

Alexander Regueiro (Sep 30 2019 at 15:20, on Zulip):

Can you explain the interp_user_fn parsing scheme that you implemented? I'm not sure how the repl is going to use it

Basically, I do this in the REPL:

    compiler.set_interp_user_fn(Some(InterpUserFn {
        placeholder: "user_body_placeholder".to_owned(),
        body: Steal::new(user_body), // user_body is independently-parsed `P<Block>`
    }));
oli (Sep 30 2019 at 15:21, on Zulip):

hmm

oli (Sep 30 2019 at 15:21, on Zulip):

if we had a querified parser you could just override the body parsing query :frown: but we don't

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

yeah...

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

I tried a lot of different approaches here

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

this was the least painful one I ended up with

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

and not too intrusive to the compiler codebase

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

shrug

oli (Sep 30 2019 at 15:22, on Zulip):

could you create a proc macro instead?

Alexander Regueiro (Sep 30 2019 at 15:22, on Zulip):

heh I thought about that

Alexander Regueiro (Sep 30 2019 at 15:23, on Zulip):

I wasn't sure how to go about that really.

Alexander Regueiro (Sep 30 2019 at 15:23, on Zulip):

a built-in macro you mean, right?

oli (Sep 30 2019 at 15:23, on Zulip):

no

Alexander Regueiro (Sep 30 2019 at 15:23, on Zulip):

rather than a proc macro per se.

Alexander Regueiro (Sep 30 2019 at 15:23, on Zulip):

hmm

Alexander Regueiro (Sep 30 2019 at 15:23, on Zulip):

they run in separate processes though

oli (Sep 30 2019 at 15:23, on Zulip):

just a proc macro, and it's the only thing in the body of your function

oli (Sep 30 2019 at 15:23, on Zulip):

then generate the appropriate body on the fly

oli (Sep 30 2019 at 15:23, on Zulip):

hmm

Alexander Regueiro (Sep 30 2019 at 15:24, on Zulip):

I have to then feed it to the proc macrothough

Alexander Regueiro (Sep 30 2019 at 15:24, on Zulip):

which is very awkward as I see it

Alexander Regueiro (Sep 30 2019 at 15:24, on Zulip):

built-in macro... maybe

oli (Sep 30 2019 at 15:24, on Zulip):

the repl could open a tcp server hosting the current body and the proc macro could fetch it

oli (Sep 30 2019 at 15:24, on Zulip):

this is similar to what I've done in priroda

oli (Sep 30 2019 at 15:25, on Zulip):

and requires no rustc parser changes

Alexander Regueiro (Sep 30 2019 at 15:25, on Zulip):

oh my.

Alexander Regueiro (Sep 30 2019 at 15:25, on Zulip):

hmm

Alexander Regueiro (Sep 30 2019 at 15:25, on Zulip):

I agree that in some sense it's cleaner...

oli (Sep 30 2019 at 15:25, on Zulip):

Anything we put into the compiler that isn't used in the compiler is always very endangered of breaking

oli (Sep 30 2019 at 15:26, on Zulip):

(or getting removed because someone notices dead code)

Alexander Regueiro (Sep 30 2019 at 15:26, on Zulip):

but a) a built-in macro would be far cleaner, b) we may be taking a performance hit for that?, c) support for an interpreter is belongs somewhat more naturally in the rustc codebase.

Alexander Regueiro (Sep 30 2019 at 15:26, on Zulip):

yeah

Alexander Regueiro (Sep 30 2019 at 15:26, on Zulip):

it's why I've tried to comment things like this

oli (Sep 30 2019 at 15:26, on Zulip):

I'm not sure about C

oli (Sep 30 2019 at 15:27, on Zulip):

that's mainly the question

Alexander Regueiro (Sep 30 2019 at 15:27, on Zulip):

you can argue both ways

oli (Sep 30 2019 at 15:27, on Zulip):

and I can't answer it

Alexander Regueiro (Sep 30 2019 at 15:27, on Zulip):

hmm

oli (Sep 30 2019 at 15:28, on Zulip):

Basically such changes need to be signed off by the compiler team and it may take some time before any decision is made

Alexander Regueiro (Sep 30 2019 at 15:29, on Zulip):

anyway, you sure about the interp tag going in attrs even though it's used by borrowck diagnostics?

Alexander Regueiro (Sep 30 2019 at 15:29, on Zulip):

okay

oli (Sep 30 2019 at 15:29, on Zulip):

I've always avoided putting things into the compiler if just clippy or miri need them

Alexander Regueiro (Sep 30 2019 at 15:30, on Zulip):

maybe we should ask Niko about this?

oli (Sep 30 2019 at 15:30, on Zulip):

anyway, you sure about the interp tag going in attrs even though it's used by borrowck diagnostics?

oh you aren't using it in the interpreter, you're modifying rustc diagnostics to know about the interpreter?

Alexander Regueiro (Sep 30 2019 at 15:30, on Zulip):

just so we don't waste time going down one particular route

Alexander Regueiro (Sep 30 2019 at 15:31, on Zulip):

precisely, yes

Alexander Regueiro (Sep 30 2019 at 15:31, on Zulip):

the interpreter sets it based on previous sessions

Alexander Regueiro (Sep 30 2019 at 15:31, on Zulip):

but then doesn't do anything with it (except serialise it)

oli (Sep 30 2019 at 15:31, on Zulip):

just so we don't waste time going down one particular route

you have given the definition of "this needs an RFC" :P

Alexander Regueiro (Sep 30 2019 at 15:31, on Zulip):

well

Alexander Regueiro (Sep 30 2019 at 15:32, on Zulip):

perhaps that one particular part of it

oli (Sep 30 2019 at 15:32, on Zulip):

preventing huge wastes of time is one reason we have RFCs, because otherwise ppl spend months on a PR, open it and then the design may need rework

Alexander Regueiro (Sep 30 2019 at 15:32, on Zulip):

Centril and others seemed averse to it however (obviously I want to avoid that effort and delay, especially given how much time I've already spent on it)

Alexander Regueiro (Sep 30 2019 at 15:32, on Zulip):

I mean, this doesn't change the user-facing surface

Alexander Regueiro (Sep 30 2019 at 15:33, on Zulip):

it's all the rustc interface

oli (Sep 30 2019 at 15:33, on Zulip):

we can make a design compiler team meeting about it

Alexander Regueiro (Sep 30 2019 at 15:33, on Zulip):

yes

Alexander Regueiro (Sep 30 2019 at 15:33, on Zulip):

if we can get by with one of those rather than a full-blown RFC, and be sure to get Niko's (and maybe mw's) input, then that would be much better.

Alexander Regueiro (Sep 30 2019 at 15:35, on Zulip):

anyway, you sure about the interp tag going in attrs even though it's used by borrowck diagnostics?

oh you aren't using it in the interpreter, you're modifying rustc diagnostics to know about the interpreter?

anyway does that mean you're okay with it as-is, as opposed to moving it into the attributes vec (which is just slightly awkward I think)?

oli (Sep 30 2019 at 15:35, on Zulip):

if we do it in the compiler and need it in the compiler yes, but I'm not sure why you're modifing borrowck diagnostics for a REPL ;)

Alexander Regueiro (Sep 30 2019 at 15:38, on Zulip):

it's basically "faking" a move or lack of initialization for a local. the changes are very localised in rustc AFAIR. it was the best/ least intrusive way I could see of accomplishing this whilst having all the code dealing with multiple eval sessions in the REPL. :-)

Alexander Regueiro (Sep 30 2019 at 15:40, on Zulip):

@oli oh, and interp_modeis used in a few random places. I can't summarise easily, so I recommend you grep the last commit of my personal branch if you're curious.

Alexander Regueiro (Sep 30 2019 at 15:40, on Zulip):

fixed the doc comment BTW

Alexander Regueiro (Sep 30 2019 at 15:41, on Zulip):

as far as I can tell, the outstanding issue is the one of the parsing placeholder vs. proc macro vs. built-in macro, which shall be discussed at a compiler design meeting? once that is resolved (and implementation changed if need be), we're basically good to merge?

oli (Sep 30 2019 at 15:41, on Zulip):

it's basically "faking" a move or lack of initialization for a local. the changes are very localised in rustc AFAIR. it was the best/ least intrusive way I could see of accomplishing this whilst having all the code dealing with multiple eval sessions in the REPL. :-)

oh so it doesn't error if you just type let x; ?

Alexander Regueiro (Sep 30 2019 at 15:43, on Zulip):

yeah. well, I want genuinely uninitialised variables to still give compiler errors, but ones initialised in some previous eval session not to error. similarly, I want ones initialised in a previous session then moved to error about being moved, not either work or fail with "uninitialized" (both of which are confusing).

oli (Sep 30 2019 at 15:45, on Zulip):

Well... the design meeting should figure out whether we're okay with sprinkling REPL stuff into the compiler

oli (Sep 30 2019 at 15:45, on Zulip):

not just the one specific case

Alexander Regueiro (Sep 30 2019 at 15:47, on Zulip):

I agree

Alexander Regueiro (Sep 30 2019 at 15:47, on Zulip):

but hopefully you appreciate that I've already tried to minimise it!

Alexander Regueiro (Sep 30 2019 at 15:47, on Zulip):

and that some stuff will be unavoidable

Alexander Regueiro (Sep 30 2019 at 15:47, on Zulip):

I think you'll agree that the main concrete point of discussion is the above one, in anycase?

oli (Sep 30 2019 at 15:50, on Zulip):

well, idk, I haven't seen the rest of the changes ^^

Alexander Regueiro (Sep 30 2019 at 15:50, on Zulip):

yeah, I mean for this PR haha

oli (Sep 30 2019 at 15:51, on Zulip):

well... it's hard to decide, without knowing the design you've come up with

oli (Sep 30 2019 at 15:51, on Zulip):

that's what I mean, we should discuss your entire design

oli (Sep 30 2019 at 15:51, on Zulip):

and whether that is how it should happen

Alexander Regueiro (Sep 30 2019 at 15:51, on Zulip):

future ones, you'll see in time... or can look at my personal branch like I said. but it will be good to get the compiler team's policy on this before I factor out new PRs from the above branch

oli (Sep 30 2019 at 15:52, on Zulip):

it's a similar situtation to https://internals.rust-lang.org/t/migrating-rustc-interface-queries-to-proper-librustc-queries/10433

oli (Sep 30 2019 at 15:52, on Zulip):

loads of work being done without the reviewers having a picture of the overall design

oli (Sep 30 2019 at 15:54, on Zulip):

think about it this way. What if you had opened a PR with just the query saying you need it later. How should a reviewer decide that that would be ok to merge

Alexander Regueiro (Sep 30 2019 at 15:57, on Zulip):

@oli yeah, well, I realise this isn't ideal... but at least I've made my personal branch of all the changes available, so that reviews can see the big picture if they so wish. hopefully you also appreciate that all this work has been the result of many weeks and countless hours of hacking, including all sorts of experimentation and (partial) reverts. anyway, I agree a compiler design meeting about this is a good idea, so let's leave the PR there until that happens, yeah? (I think we and mark-simulacrum agree it's a good state now modulo those concerns.) sound fair? :-)

oli (Sep 30 2019 at 15:57, on Zulip):

code isn't design ;) it's implementation. If you could write up an overview for a design meeting that would be great

Alexander Regueiro (Sep 30 2019 at 15:58, on Zulip):

well, there's either explicit or implicit design that goes into any implementation. mainly implicit in this case!

oli (Sep 30 2019 at 15:58, on Zulip):

that's totally fine

Alexander Regueiro (Sep 30 2019 at 15:58, on Zulip):

I'll try to write up something yes

oli (Sep 30 2019 at 15:58, on Zulip):

I mean to exctract the design in hindsight

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

when do you want to schedule this for?

oli (Sep 30 2019 at 15:59, on Zulip):

which is a totally alright thing to do (most research works this way :P)

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

I can do a 1/2 page - 1 page summary or something

oli (Sep 30 2019 at 15:59, on Zulip):

I checked the schedule, and the next three fridays are used

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

yeah, that's my experience too.

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

ouch

oli (Sep 30 2019 at 15:59, on Zulip):

maybe in 3 weeks gets dropped

oli (Sep 30 2019 at 15:59, on Zulip):

it's unclear

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

can't do a "special meeting" in a week or two I suppose?

Alexander Regueiro (Sep 30 2019 at 15:59, on Zulip):

I know it might be asking too much ^

oli (Sep 30 2019 at 16:00, on Zulip):

but if you create an issue with the document in https://github.com/rust-lang/compiler-team/ with a hack.md connected of your design

Alexander Regueiro (Sep 30 2019 at 16:00, on Zulip):

okay

oli (Sep 30 2019 at 16:00, on Zulip):

(deleted)

oli (Sep 30 2019 at 16:00, on Zulip):

is the procedure for this

oli (Sep 30 2019 at 16:00, on Zulip):

sorry, https://rust-lang.github.io/compiler-team/procedures/steering-meeting/

Alexander Regueiro (Sep 30 2019 at 16:01, on Zulip):

okay

Alexander Regueiro (Sep 30 2019 at 16:01, on Zulip):

Also, I can participate in the compiler design meeting perhaps. not as a team member obviously, but to answer questions, which I think would make sense?

Alexander Regueiro (Sep 30 2019 at 16:01, on Zulip):

I'll draft something too though.

oli (Sep 30 2019 at 16:01, on Zulip):

heh everyone can participate, but in the REPL one, yes, I would very much hope you'd be there

oli (Sep 30 2019 at 16:01, on Zulip):

otherwise it makes no sense to hold

Alexander Regueiro (Sep 30 2019 at 16:02, on Zulip):

yeah, thought so :-P

Alexander Regueiro (Sep 30 2019 at 16:03, on Zulip):

just trying to be respectful of not intruding on compiler team things

Alexander Regueiro (Sep 30 2019 at 16:03, on Zulip):

but I agree, it makes the meeting hugely more useful

Alexander Regueiro (Sep 30 2019 at 16:03, on Zulip):

anyway...

Alexander Regueiro (Sep 30 2019 at 16:03, on Zulip):

thanks for the review. we'll take things from there I guess.

Alexander Regueiro (Sep 30 2019 at 16:03, on Zulip):

bye for now.

pnkfelix (Oct 01 2019 at 11:03, on Zulip):

Also, I can participate in the compiler design meeting perhaps. not as a team member obviously, but to answer questions, which I think would make sense?

Oh yeah, we should make that clearer in the docs for these meetings: I think the intention is absolutely to invite the relevant parties to any particular design meeting. There's no reason I can see to limit participation solely to compiler-team members. (And besides, we invite the broader audience of compiler-team/meeting anyway.)

Alexander Regueiro (Oct 01 2019 at 16:56, on Zulip):

@oli oops, just noticed now Mark-Simulacrum r+'ed it... oh well, just as well it didn't succeed.

RalfJ (Oct 09 2019 at 15:58, on Zulip):

@Alexander Regueiro for perf, I'd recomment benchmarking to figure out where the bottlenecks are

RalfJ (Oct 09 2019 at 15:58, on Zulip):

we have done basically zero perf work on Miri so I expect there to be some low-hanging fruit

RalfJ (Oct 09 2019 at 15:59, on Zulip):

but this will also highly depend on the benchmark you are picking

Alexander Regueiro (Oct 09 2019 at 15:59, on Zulip):

@RalfJ yep, good idea. there are already benchmarks, which is nice. disabling validations is a no-brainer, but I'll have a look...

Alexander Regueiro (Oct 09 2019 at 15:59, on Zulip):

any low-hanging fruit that comes to mind immediately, which I should look into?

RalfJ (Oct 09 2019 at 15:59, on Zulip):

and there's a trade-off between code clarify and perf. I'd be worried about making Miri significantly more messy even if that helps perf, because it is already a hard-to-maintain piece of rustc with subtle correctness invariants.

RalfJ (Oct 09 2019 at 16:00, on Zulip):

any low-hanging fruit that comes to mind immediately, which I should look into?

your guess is probably as good as mine. I am wondering if all our layout computations are costing us or not -- they are cached but hitting the cache is still non-zero-cost. but really I dont dare making any guesses.

RalfJ (Oct 09 2019 at 16:01, on Zulip):

@oli @pnkfelix as for a "design meeting", if it involves the miri engine I'd appreciate being involved, or at least getting the chance to look at the summary of the mtg or so.

Alexander Regueiro (Oct 09 2019 at 16:41, on Zulip):

sounds fair

Alexander Regueiro (Oct 09 2019 at 16:42, on Zulip):

@RalfJ right now my REPL itself is a fork of miri, which I regular rebase on top of... but in the future ideally we can factor out the miri engine.

RalfJ (Oct 09 2019 at 16:43, on Zulip):

the "miri engine" is already factored out, it lives in librustc_mir/interpret in the rustc repo

Alexander Regueiro (Oct 09 2019 at 19:58, on Zulip):

@RalfJ yeah, so I don't mean the engine then... I mean the stuff in the miri repo (lib part) that can be shared between miri the tool and my repl tool (which is the vast majority)

Alexander Regueiro (Oct 09 2019 at 20:04, on Zulip):

basically just one or two new intrinsics I think

Alexander Regueiro (Oct 09 2019 at 20:04, on Zulip):

is the difference

Alexander Regueiro (Oct 09 2019 at 20:05, on Zulip):

maybe that can go into miri itself. if there are other diffs, they're small!

RalfJ (Oct 09 2019 at 20:07, on Zulip):

I see. yeah we don't guarantee stability for that but other than that, makes sense ;)

Alexander Regueiro (Oct 09 2019 at 20:30, on Zulip):

@RalfJ yeah, maybe could have a toolstate sort of situation though. I can see it working. I've tried to expand on top of miri as much as possible, rather than modifying it... so yeah, the main things are a different machine implementation (necessary I think) and the intrinsics. should be workable, but nothing to concern ourselves with quite yet. :-)

RalfJ (Oct 10 2019 at 08:19, on Zulip):

given that Miri does not change remotely as fast as rustc does, it might be enough for you to just have a cronjob that regularly tests against Miri master

oli (Oct 10 2019 at 09:03, on Zulip):

That's how priroda works, too

Alexander Regueiro (Oct 12 2019 at 17:59, on Zulip):

sounds reasonable yeah

RalfJ (Oct 12 2019 at 18:36, on Zulip):

@Alexander Regueiro I just learned that rustc gained a lot of speed on some benchmarks by avoiding layout_of in a hot code path. That confirms the suspicion I raised above that right now, having the layout of everything everywhere is our biggest bottleneck.

RalfJ (Oct 12 2019 at 18:36, on Zulip):

however, adding that layout everywhere also helped to uncover and fix tons of bugs

RalfJ (Oct 12 2019 at 18:37, on Zulip):

so when optimizing this we have to be careful to not make our API more fragile

Alexander Regueiro (Oct 12 2019 at 18:37, on Zulip):

@RalfJ Cool. Thanks for letting me know. I'll see if I can at the very least cache it, if not avoid calls to it.

Alexander Regueiro (Oct 12 2019 at 18:37, on Zulip):

Maybe with a cfg option.

RalfJ (Oct 12 2019 at 18:37, on Zulip):

it is cached

Alexander Regueiro (Oct 12 2019 at 18:37, on Zulip):

ah

RalfJ (Oct 12 2019 at 18:37, on Zulip):

the rustc query mechanism caches it for us

RalfJ (Oct 12 2019 at 18:37, on Zulip):

but it's still a hashtable lookup and some more stuff even for a cache hit, which in hot loops is a lot

RalfJ (Oct 12 2019 at 18:38, on Zulip):

so you'll still need to profile

RalfJ (Oct 12 2019 at 18:38, on Zulip):

but this would be the first thing I'd look for in a profile ;)

Alexander Regueiro (Oct 12 2019 at 18:39, on Zulip):

aha

Alexander Regueiro (Oct 12 2019 at 18:39, on Zulip):

yeah

Alexander Regueiro (Oct 12 2019 at 18:39, on Zulip):

I will profile, for sure

Alexander Regueiro (Oct 12 2019 at 18:39, on Zulip):

ta

Last update: Nov 17 2019 at 08:10UTC