Stream: t-compiler/wg-self-profile

Topic: "Finish the MVP" meeting


mw (Oct 22 2019 at 08:14, on Zulip):

Hello @WG-self-profile, @Wesley Wiser and I chatted a bit yesterday and concluded that it:

mw (Oct 22 2019 at 08:17, on Zulip):

How about next Monday, the usual time?
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=28&hour=11&min=0&sec=0&p1=37&p2=263

Wesley Wiser (Oct 22 2019 at 09:59, on Zulip):

That works for me

simulacrum (Oct 22 2019 at 12:05, on Zulip):

I can do that, yeah

simulacrum (Oct 22 2019 at 12:05, on Zulip):

are there leftover bits to the perf.rlo MVP? I sort of thought it was done

mw (Oct 22 2019 at 12:06, on Zulip):

there are a few things that should be cleaned up

simulacrum (Oct 22 2019 at 12:06, on Zulip):

it'd be good to open an issue or something to track them :)

simulacrum (Oct 22 2019 at 12:06, on Zulip):

I might be able to knock them out before monday then

mw (Oct 22 2019 at 12:06, on Zulip):

@Wesley Wiser has added a few points to the tracking issue: https://github.com/rust-lang/rust/issues/58967

mw (Oct 22 2019 at 12:07, on Zulip):

and I'm working on a more detailed review of the "details" and "comparison" views

mw (Oct 22 2019 at 12:07, on Zulip):

I'll open issues :)

Wesley Wiser (Oct 22 2019 at 12:07, on Zulip):

I'm currently working on "Write high-level crate docs for measureme"

simulacrum (Oct 22 2019 at 12:08, on Zulip):

pasted image

Maybe you meant MVP in general? perf.rlo checks look done

simulacrum (Oct 22 2019 at 12:08, on Zulip):

in any case issues seem fine

mw (Oct 22 2019 at 12:15, on Zulip):

yes, the MVP in general

mw (Oct 22 2019 at 12:16, on Zulip):

the detailed view and detailed comparison view are not quite at where I'd like them to be

mw (Oct 22 2019 at 15:23, on Zulip):

@Wesley Wiser @simulacrum could one of you add the meeting to compiler team calendar?

Wesley Wiser (Oct 22 2019 at 15:23, on Zulip):

Sure

mw (Oct 22 2019 at 15:23, on Zulip):

thanks!

simulacrum (Oct 22 2019 at 15:24, on Zulip):

I don't think I have access

Wesley Wiser (Oct 22 2019 at 15:25, on Zulip):

Should we just have it in this thread?

simulacrum (Oct 22 2019 at 15:25, on Zulip):

Yeah seems fine

Wesley Wiser (Oct 22 2019 at 15:26, on Zulip):

Done

simulacrum (Oct 23 2019 at 13:28, on Zulip):

Closed the three issues @mw filed and went a little farther on the "totals" total time % column which'll check against cpu-clock from perf stat and give you the time% we computed vs. that

simulacrum (Oct 23 2019 at 13:29, on Zulip):

(I initially went with wall-time but that already falls down due to LLVM)

mw (Oct 23 2019 at 14:13, on Zulip):

Yeah, I opened https://github.com/rust-lang/measureme/issues/65 as a reminder about wall time. It's unclear to me how to handle it.

simulacrum (Oct 27 2019 at 19:03, on Zulip):

I believe the meeting tomorrow should start at 7pm UTC -- but due to DST changes, I'm not sure if that's actually true. I can make 7 or 8pm, but 6pm UTC would likely be harder. If I'm told so in the next ~7 hours I can make it work though.

Wesley Wiser (Oct 28 2019 at 01:02, on Zulip):

@simulacrum I think it's supposed to be 11:00 UTC: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=10&day=28&hour=11&min=0&sec=0&p1=37&p2=263

simulacrum (Oct 28 2019 at 01:02, on Zulip):

Hm.

simulacrum (Oct 28 2019 at 01:03, on Zulip):

Yeah, that does seem right. Maybe I mistyped or looked the wrong thing up. 11utc sounds like what I expected though so we should be good.

Wesley Wiser (Oct 28 2019 at 01:04, on Zulip):

Maybe I messed up the Google Calendar event?

Wesley Wiser (Oct 28 2019 at 01:05, on Zulip):

It looks right to me but I'm in EST so I can't really tell

mw (Oct 28 2019 at 08:59, on Zulip):

11:00 UTC is the time I have for it too

simulacrum (Oct 28 2019 at 10:59, on Zulip):

o/

mw (Oct 28 2019 at 10:59, on Zulip):

hello!

simulacrum (Oct 28 2019 at 11:02, on Zulip):

Are we waiting for anyone other than @Wesley Wiser today?

mw (Oct 28 2019 at 11:02, on Zulip):

no, i don't think so

mw (Oct 28 2019 at 11:05, on Zulip):

alright, it looks like @Wesley Wiser might not be available today

mw (Oct 28 2019 at 11:06, on Zulip):

we can still chat a little bit about what's left to do for the MVP

mw (Oct 28 2019 at 11:06, on Zulip):

it's mostly nits I think

mw (Oct 28 2019 at 11:07, on Zulip):

I'll open issues for the things that don't need discussion

mw (Oct 28 2019 at 11:07, on Zulip):

but for some things it might make sense to chat about them now

mw (Oct 28 2019 at 11:08, on Zulip):

one thing @Wesley Wiser and I thought that it would make sense to display the absolute time difference in the comparison view instead of the time that commit B used

mw (Oct 28 2019 at 11:08, on Zulip):

e.g. here

mw (Oct 28 2019 at 11:08, on Zulip):

https://perf.rust-lang.org/detailed-query.html?commit=95f437b3cfb2fec966d7eaf69d7c2e36f9c274d1&base_commit=0f677c65e867d93a47ccbaeaf6e6725cde8c5ff6&benchmark=html5ever-check&run_name=clean

mw (Oct 28 2019 at 11:09, on Zulip):

the typeck_tables_of lines says 0.406 seconds because that's how long it took

mw (Oct 28 2019 at 11:10, on Zulip):

instead it could say -0.004 seconds

simulacrum (Oct 28 2019 at 11:10, on Zulip):

the absolute diff is available if you hover the percentage

simulacrum (Oct 28 2019 at 11:10, on Zulip):

we could flip that (display absolute, hover for percent)

simulacrum (Oct 28 2019 at 11:10, on Zulip):

absolute time does seem useful

mw (Oct 28 2019 at 11:11, on Zulip):

hm, I wonder

mw (Oct 28 2019 at 11:11, on Zulip):

(hello @Wesley Wiser !)

Wesley Wiser (Oct 28 2019 at 11:11, on Zulip):

Hi, sorry I ran into some connectivity issues this morning

mw (Oct 28 2019 at 11:11, on Zulip):

no worries

Wesley Wiser (Oct 28 2019 at 11:12, on Zulip):

Sorting by absolute diff would also be nice since it would make it easy to see where speedups/slowdowns are coming from

mw (Oct 28 2019 at 11:12, on Zulip):

yes, that's right

simulacrum (Oct 28 2019 at 11:12, on Zulip):

hm, true

simulacrum (Oct 28 2019 at 11:13, on Zulip):

implementing sorting by the diff columns would not be too hard

mw (Oct 28 2019 at 11:13, on Zulip):

having the change as a percentage is also interesting because that shows where big changes are

simulacrum (Oct 28 2019 at 11:13, on Zulip):

in some sense I fear this adding of sorting by XYZ since it adds a lot of "complexity" that might not be warranted

simulacrum (Oct 28 2019 at 11:14, on Zulip):

but in this particular case it probably makes sense -- maybe a dedicated column just for the "wall" time

simulacrum (Oct 28 2019 at 11:14, on Zulip):

we could have B (current), delta (absolute), delta (percent) columns for the time and sort by any of those

mw (Oct 28 2019 at 11:15, on Zulip):

that sounds good

mw (Oct 28 2019 at 11:15, on Zulip):

we have to make sure that the column labels make it clear what's what

mw (Oct 28 2019 at 11:16, on Zulip):

also, we can get rid of the "cache misses" column in both views

simulacrum (Oct 28 2019 at 11:16, on Zulip):

I was thinking just the current delta symbols with (s) and (%) or so

mw (Oct 28 2019 at 11:17, on Zulip):

I think the B (current) column is the one that's the least clear

simulacrum (Oct 28 2019 at 11:17, on Zulip):

ah -- so that we can leave as-is, i.e., just "Time"

simulacrum (Oct 28 2019 at 11:17, on Zulip):

but that's not super clear too

mw (Oct 28 2019 at 11:18, on Zulip):

Time (commit B) or something like that

simulacrum (Oct 28 2019 at 11:18, on Zulip):

that's a bit long

simulacrum (Oct 28 2019 at 11:18, on Zulip):

like the times are ~4-6 digits -- that'll be like ~30 characters I think?

mw (Oct 28 2019 at 11:18, on Zulip):

Time (new) ?

simulacrum (Oct 28 2019 at 11:18, on Zulip):

new works, I think

simulacrum (Oct 28 2019 at 11:19, on Zulip):

maybe we can split it onto two lines, that might look nice

simulacrum (Oct 28 2019 at 11:19, on Zulip):

(we should file issues for these after meeting, btw)

mw (Oct 28 2019 at 11:19, on Zulip):

yup

Wesley Wiser (Oct 28 2019 at 11:19, on Zulip):

new also has a clear opposite: old which I think is pretty intuitive for how most people use perf.rlo

mw (Oct 28 2019 at 11:20, on Zulip):

cool

mw (Oct 28 2019 at 11:20, on Zulip):

btw, @simulacrum, the whole page looks really nice now

mw (Oct 28 2019 at 11:20, on Zulip):

i.e. the styling of the table and such

mw (Oct 28 2019 at 11:21, on Zulip):

ok, I already mentioned that the "cache misses" column can be removed

simulacrum (Oct 28 2019 at 11:21, on Zulip):

hm, why?

mw (Oct 28 2019 at 11:21, on Zulip):

it's kind of useless because we don't record cache hits on perf.rlo

mw (Oct 28 2019 at 11:22, on Zulip):

so it's always the same as "invocations"

simulacrum (Oct 28 2019 at 11:22, on Zulip):

ah, I see. It might be good to make summarize not include the field or w/e if it doesn't actually know

simulacrum (Oct 28 2019 at 11:22, on Zulip):

maybe null

simulacrum (Oct 28 2019 at 11:22, on Zulip):

and then we can drop the column

mw (Oct 28 2019 at 11:22, on Zulip):

yeah

simulacrum (Oct 28 2019 at 11:22, on Zulip):

(in parallel with that, of course, but the point stands)

mw (Oct 28 2019 at 11:23, on Zulip):

the "invocations" column really means "how many times was the provider executed" so we might want to rename that too

mw (Oct 28 2019 at 11:24, on Zulip):

if you record cache hits, then invocations = hits + misses

mw (Oct 28 2019 at 11:24, on Zulip):

which makes sense, but if you only record the misses, then "invocations" is a bit misleading as a label

simulacrum (Oct 28 2019 at 11:24, on Zulip):

hm, yeah -- maybe "distinct results"? I guess that's not true either

mw (Oct 28 2019 at 11:25, on Zulip):

distinct keys would be true

simulacrum (Oct 28 2019 at 11:25, on Zulip):

we could just do Keys or "Key Count" or something

mw (Oct 28 2019 at 11:25, on Zulip):

although only for queries, not for regular functions

mw (Oct 28 2019 at 11:25, on Zulip):

"uncached invocations" :P

simulacrum (Oct 28 2019 at 11:26, on Zulip):

hm, so right now invocations = misses, right?

mw (Oct 28 2019 at 11:26, on Zulip):

yes

simulacrum (Oct 28 2019 at 11:26, on Zulip):

so "Cache Misses" could be the title

Wesley Wiser (Oct 28 2019 at 11:26, on Zulip):

Some of this terminology was kind of vague on purpose because we have both queries, with stronger semantics, and arbitrary timed events which have almost no semantics.

simulacrum (Oct 28 2019 at 11:26, on Zulip):

i.e., in some sense we can just delete the invocation column rather than the cache miss column, but in reality rename them and swap sort of :)

mw (Oct 28 2019 at 11:27, on Zulip):

yeah

mw (Oct 28 2019 at 11:27, on Zulip):

that still leaves Wesley's point

mw (Oct 28 2019 at 11:27, on Zulip):

i.e. regular functions don't have a cache

simulacrum (Oct 28 2019 at 11:27, on Zulip):

do we encode that difference anywhere in the summarize output?

mw (Oct 28 2019 at 11:27, on Zulip):

I don't think so

Wesley Wiser (Oct 28 2019 at 11:28, on Zulip):

To be clear, I'm not against improving the names but we should be careful not to name them things that would be (too) misleading.

Wesley Wiser (Oct 28 2019 at 11:28, on Zulip):

No, we don't.

mw (Oct 28 2019 at 11:28, on Zulip):

"full executions"?

simulacrum (Oct 28 2019 at 11:29, on Zulip):

that seems fine

Wesley Wiser (Oct 28 2019 at 11:29, on Zulip):

:thumbs_up:

mw (Oct 28 2019 at 11:29, on Zulip):

I'd be ok with a column name that is not immediately understandable so that one has to go to the mouseover

simulacrum (Oct 28 2019 at 11:29, on Zulip):

I think we should get a paragraph similar to the wall time snippet

simulacrum (Oct 28 2019 at 11:29, on Zulip):

(vs hover)

simulacrum (Oct 28 2019 at 11:29, on Zulip):

no one can ever find my hover text :)

mw (Oct 28 2019 at 11:30, on Zulip):

I use it extensively :)

mw (Oct 28 2019 at 11:31, on Zulip):

one question: the "loading" column seems to be all zeros here: https://perf.rust-lang.org/detailed-query.html?sort_idx=-2&commit=95f437b3cfb2fec966d7eaf69d7c2e36f9c274d1&benchmark=html5ever-check&run_name=clean

simulacrum (Oct 28 2019 at 11:31, on Zulip):

the times are all less than 0.000 I believe

mw (Oct 28 2019 at 11:31, on Zulip):

but the "total" line shows a non-zero number

simulacrum (Oct 28 2019 at 11:31, on Zulip):

but in sum you add up? that's my only conclusion

simulacrum (Oct 28 2019 at 11:32, on Zulip):

I've been meaning to switch that column to say milliseconds insead of seconds

simulacrum (Oct 28 2019 at 11:32, on Zulip):

since it's clear that loading is super fast

mw (Oct 28 2019 at 11:32, on Zulip):

I don't think it could add up to that much, right?

simulacrum (Oct 28 2019 at 11:33, on Zulip):

There are a few non-zero entries

mw (Oct 28 2019 at 11:33, on Zulip):

too few lines for that

mw (Oct 28 2019 at 11:33, on Zulip):

there are?

simulacrum (Oct 28 2019 at 11:33, on Zulip):

yeah, if you sort by ti

simulacrum (Oct 28 2019 at 11:33, on Zulip):

https://perf.rust-lang.org/detailed-query.html?sort_idx=-7&commit=95f437b3cfb2fec966d7eaf69d7c2e36f9c274d1&base_commit=0f677c65e867d93a47ccbaeaf6e6725cde8c5ff6&benchmark=html5ever-check&run_name=clean%20incremental

mw (Oct 28 2019 at 11:34, on Zulip):

I'm looking at this one: https://perf.rust-lang.org/detailed-query.html?sort_idx=-2&commit=95f437b3cfb2fec966d7eaf69d7c2e36f9c274d1&benchmark=html5ever-check&run_name=clean

mw (Oct 28 2019 at 11:35, on Zulip):

there's probably a bug somewhere

simulacrum (Oct 28 2019 at 11:36, on Zulip):

there's 158 rows, so that should be an average of 0.003297468354

simulacrum (Oct 28 2019 at 11:36, on Zulip):

yeah does seem plausible that it's a bug

simulacrum (Oct 28 2019 at 11:36, on Zulip):

if you pop open an issue I can investigate -- we might not be displaying times quite right or so

mw (Oct 28 2019 at 11:36, on Zulip):

will do

mw (Oct 28 2019 at 11:36, on Zulip):

ok, I have two more things that might be worth discussion:

mw (Oct 28 2019 at 11:37, on Zulip):
  1. could we have per-commit information displayed at the top
mw (Oct 28 2019 at 11:37, on Zulip):
  1. do we want to make an announcement that this is "done"
simulacrum (Oct 28 2019 at 11:38, on Zulip):

could we have per-commit information displayed at the top

Not sure what this means :)

mw (Oct 28 2019 at 11:38, on Zulip):

re (1): it would be nice to display some information that doesn't fit into the table

simulacrum (Oct 28 2019 at 11:38, on Zulip):

I think s/done/exists/ but yeah, that seems like a good idea

mw (Oct 28 2019 at 11:38, on Zulip):

like "wall-time"

simulacrum (Oct 28 2019 at 11:38, on Zulip):

Ah. Yes, I agree, that'd probably be good

simulacrum (Oct 28 2019 at 11:38, on Zulip):

I've also wanted us to add support for arbitrary single-point metrics

simulacrum (Oct 28 2019 at 11:38, on Zulip):

like e.g. "hash table size" and such

mw (Oct 28 2019 at 11:39, on Zulip):

yes, things like that

simulacrum (Oct 28 2019 at 11:39, on Zulip):

I think we should do both then

mw (Oct 28 2019 at 11:39, on Zulip):

once the infrastructure is in place, it shouldn't be too hard to add something right?

simulacrum (Oct 28 2019 at 11:39, on Zulip):

no, it's pretty easy I think

simulacrum (Oct 28 2019 at 11:40, on Zulip):

hard to do without raw data, but once we have that pretty easy

mw (Oct 28 2019 at 11:40, on Zulip):

the comparison view should display both side-by-side

mw (Oct 28 2019 at 11:40, on Zulip):

summarize would have to be extended to include wall-time

mw (Oct 28 2019 at 11:41, on Zulip):

one way we could do this is:

mw (Oct 28 2019 at 11:41, on Zulip):

extend summarize's output by a table of key-value pairs

mw (Oct 28 2019 at 11:41, on Zulip):

and then have perf.rlo just render that

simulacrum (Oct 28 2019 at 11:42, on Zulip):

Total wall time we already have from perf stat

mw (Oct 28 2019 at 11:42, on Zulip):

ok

simulacrum (Oct 28 2019 at 11:42, on Zulip):

But kv pairs is exactly what I want

mw (Oct 28 2019 at 11:42, on Zulip):

yeah, other consumers of summarize might be interested too

mw (Oct 28 2019 at 11:43, on Zulip):

does that sound good to you too, @Wesley Wiser ?

Wesley Wiser (Oct 28 2019 at 11:43, on Zulip):

Yeah, that seems reasonable

mw (Oct 28 2019 at 11:43, on Zulip):

the question is, do we want it for the MVP?

simulacrum (Oct 28 2019 at 11:43, on Zulip):

Another thing I've wanted from summarize is standard deviation

simulacrum (Oct 28 2019 at 11:43, on Zulip):

Instead of just a sum

simulacrum (Oct 28 2019 at 11:44, on Zulip):

(for the time metrics)

mw (Oct 28 2019 at 11:44, on Zulip):

yeah, that makes sense

mw (Oct 28 2019 at 11:44, on Zulip):

so maybe we want to review this in more depth, but not add any of this to the MVP

simulacrum (Oct 28 2019 at 11:44, on Zulip):

I think it makes sense to put a few in the MVP

mw (Oct 28 2019 at 11:45, on Zulip):

ok

simulacrum (Oct 28 2019 at 11:45, on Zulip):

KV pairs in particular

simulacrum (Oct 28 2019 at 11:45, on Zulip):

Since I want people to come along and instrument stuff

mw (Oct 28 2019 at 11:45, on Zulip):

I just want to avoid postponing the MVP for too long

simulacrum (Oct 28 2019 at 11:45, on Zulip):

I imagine this is like a week's work?

simulacrum (Oct 28 2019 at 11:45, on Zulip):

If that's not true then yeah we can drop

mw (Oct 28 2019 at 11:46, on Zulip):

I'm not sure, it spans summarize, measureme, and perf.rlo

mw (Oct 28 2019 at 11:46, on Zulip):

so we should have a clean design before we do it, I think

simulacrum (Oct 28 2019 at 11:47, on Zulip):

Okay - probably true - let's drop then

mw (Oct 28 2019 at 11:47, on Zulip):

I'd rather we don't make it part of the MVP

Wesley Wiser (Oct 28 2019 at 11:47, on Zulip):

We already have people using the self-profile stuff and getting value out of it so it feels to me like we're quickly leaving MVP territory

mw (Oct 28 2019 at 11:47, on Zulip):

I'd be OK with just having wall-time though

mw (Oct 28 2019 at 11:47, on Zulip):

since that does not need changes from summarize just now

simulacrum (Oct 28 2019 at 11:48, on Zulip):

I would not want wall time to be separate from the other bits if it's eventually something we show

simulacrum (Oct 28 2019 at 11:48, on Zulip):

But otherwise I don't care much

mw (Oct 28 2019 at 11:48, on Zulip):

alright, let's do it all in one go after the MVP then

mw (Oct 28 2019 at 11:48, on Zulip):

ok

Wesley Wiser (Oct 28 2019 at 11:48, on Zulip):

The key-value api is really interesting though and I imagine there's a lot of stuff that would be very useful to various people if we had that functionality.

mw (Oct 28 2019 at 11:49, on Zulip):

yes

Wesley Wiser (Oct 28 2019 at 11:49, on Zulip):

eg wg-traits might be interested in stats on how many trait predicates get solved per compilation or something like that

mw (Oct 28 2019 at 11:49, on Zulip):

yeah

mw (Oct 28 2019 at 11:49, on Zulip):

ok, so the MVP will be done soon then

simulacrum (Oct 28 2019 at 11:50, on Zulip):

The polish points we identified are I think 1-2 hours of work - do we want to loosely remeet at this time next week for go/no go on MVP m

mw (Oct 28 2019 at 11:50, on Zulip):

just the issues that we'll open after this meeting

mw (Oct 28 2019 at 11:50, on Zulip):

we can do that, yeah

simulacrum (Oct 28 2019 at 11:50, on Zulip):

Or we can even just do it, say Thursday

Wesley Wiser (Oct 28 2019 at 11:50, on Zulip):

seems fine yeah

mw (Oct 28 2019 at 11:51, on Zulip):

we can just do it asynchronously

mw (Oct 28 2019 at 11:51, on Zulip):

once we do give the go, we should do a little announcement somewhere

mw (Oct 28 2019 at 11:51, on Zulip):

definitely the compiler team meeting

mw (Oct 28 2019 at 11:51, on Zulip):

but also irlo?

simulacrum (Oct 28 2019 at 11:51, on Zulip):

Team blog seems appropriate

Wesley Wiser (Oct 28 2019 at 11:51, on Zulip):

Inside-Rust blog?

mw (Oct 28 2019 at 11:52, on Zulip):

yes, sounds good

simulacrum (Oct 28 2019 at 11:52, on Zulip):

We can cross post to irlo

mw (Oct 28 2019 at 11:53, on Zulip):

alright

mw (Oct 28 2019 at 11:53, on Zulip):

then I just need to open some issues :)

mw (Oct 28 2019 at 11:54, on Zulip):

is there anything else you'd like to discuss?

Wesley Wiser (Oct 28 2019 at 11:54, on Zulip):

Is it too early to start thinking about what comes after the mvp?

simulacrum (Oct 28 2019 at 11:54, on Zulip):

I don't think so -- I would like to make sure we have an issue to track the KV stuff -- but that seems fine

mw (Oct 28 2019 at 11:55, on Zulip):

we should start collecting future plans so we can prioritize

simulacrum (Oct 28 2019 at 11:55, on Zulip):

personally I think next stage after KV stuff is to figure out a strategy for getting the real keys in the output (e.g., associating with input basically)

mw (Oct 28 2019 at 11:55, on Zulip):

yeah, I'm working on query keys already

mw (Oct 28 2019 at 11:55, on Zulip):

let me know if you want to be in the loop about that

simulacrum (Oct 28 2019 at 11:56, on Zulip):

loosely yes (but I don't actually care too much) beyond wanting to use it

mw (Oct 28 2019 at 11:56, on Zulip):

I'll cc you on the relevant PRs then

mw (Oct 28 2019 at 11:57, on Zulip):

and try to write good documentation that explains how it works

simulacrum (Oct 28 2019 at 11:57, on Zulip):

:thumbs_up: -- I can definitely provide feedback/review on those PRs, I think

mw (Oct 28 2019 at 11:57, on Zulip):

it's always good to have more people who have an idea how the code works

mw (Oct 28 2019 at 11:58, on Zulip):

and sanity check my implementation :)

mw (Oct 28 2019 at 11:58, on Zulip):

@Wesley Wiser might be looking into making measureme a rustup component

mw (Oct 28 2019 at 11:59, on Zulip):

or rather, the measureme tools

Wesley Wiser (Oct 28 2019 at 11:59, on Zulip):

Now that we're recording process id and arguments in the profile data, I'd like to look at extending crox to show multiple rustc invocations in the same json file. I think it will end up similar to the cargo -Z timing stuff but much more detailed.

mw (Oct 28 2019 at 11:59, on Zulip):

oh yeah, that would be awesome

simulacrum (Oct 28 2019 at 11:59, on Zulip):

Now that we're recording process id and arguments in the profile data, I'd like to look at extending crox to show multiple rustc invocations in the same json file. I think it will end up similar to the cargo -Z timing stuff but much more detailed.

I've wanted to get cargo's stuff to 'link in' self profile graphs, but that sounds even better

Wesley Wiser (Oct 28 2019 at 11:59, on Zulip):

I'm also looking into that. I've found a few relevant PRs that hopefully I can use as a reference on how to do that because I've never done anything with rustup components before and I can't find any relevant docs

simulacrum (Oct 28 2019 at 12:00, on Zulip):

@Wesley Wiser I think @cuviper has recently done quite a bit here to get rustc-dev split working, so maybe talk to them?

Wesley Wiser (Oct 28 2019 at 12:00, on Zulip):

Ah ok

Wesley Wiser (Oct 28 2019 at 12:00, on Zulip):

Thanks!

mw (Oct 28 2019 at 12:00, on Zulip):

there's also tromey's PRs that added some debuginfo stuff?

mw (Oct 28 2019 at 12:01, on Zulip):

lldb, I think?

simulacrum (Oct 28 2019 at 12:01, on Zulip):

those are older I think, but yes

Wesley Wiser (Oct 28 2019 at 12:01, on Zulip):

I found prs from oli and manish that added clippy and miri but they're pretty old now

mw (Oct 28 2019 at 12:01, on Zulip):

yes, the newer work is the better reference

mw (Oct 28 2019 at 12:02, on Zulip):

at some point I also want to look into providing full profiles on perf.rlo

mw (Oct 28 2019 at 12:02, on Zulip):

see: https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile/topic/Making.20full.20profiles.20available.20on.20perf.2Erlo

mw (Oct 28 2019 at 12:02, on Zulip):

mostly find out how feasible it is

simulacrum (Oct 28 2019 at 12:03, on Zulip):

I plan on doing some work in the short term that makes it "easier" by moving the main data store to S3 vs. a github repo

simulacrum (Oct 28 2019 at 12:03, on Zulip):

(I feel bad for having ~6GB of data in GH)

mw (Oct 28 2019 at 12:03, on Zulip):

that sounds food

mw (Oct 28 2019 at 12:03, on Zulip):

:)

mw (Oct 28 2019 at 12:03, on Zulip):

that sounds good

mw (Oct 28 2019 at 12:03, on Zulip):

it is lunch time here

Wesley Wiser (Oct 28 2019 at 12:04, on Zulip):

We had a great pr from andjo403 a couple weeks ago that cut our crox json output by almost half so hopefully it's a bit more feasible now :)

mw (Oct 28 2019 at 12:04, on Zulip):

nice

mw (Oct 28 2019 at 12:05, on Zulip):

ok

mw (Oct 28 2019 at 12:05, on Zulip):

let's finish the MVP and collect ideas on what to do next

Wesley Wiser (Oct 28 2019 at 12:05, on Zulip):

I guess somebody (did mw volunteer?) is going to open issues about the remaining work items?

mw (Oct 28 2019 at 12:05, on Zulip):

and then we can have another meeting where we prioritize

mw (Oct 28 2019 at 12:06, on Zulip):

yes

mw (Oct 28 2019 at 12:06, on Zulip):

I'm happy to do it

Wesley Wiser (Oct 28 2019 at 12:06, on Zulip):

Thanks! :)

mw (Oct 28 2019 at 12:07, on Zulip):

but first I need to eat something

mw (Oct 28 2019 at 12:07, on Zulip):

thanks for attending, everyone!

simulacrum (Oct 28 2019 at 12:07, on Zulip):

\o

andjo403 (Nov 08 2019 at 20:47, on Zulip):

Now that we're recording process id and arguments in the profile data, I'd like to look at extending crox to show multiple rustc invocations in the same json file. I think it will end up similar to the cargo -Z timing stuff but much more detailed.

@Wesley Wiser have you started working on this otherwise I have been thinking on this for a while and can maybe take a look at it during the weekend

Wesley Wiser (Nov 08 2019 at 20:49, on Zulip):

I have a few small changes locally to add some supporting stuff in measureme but I haven't started modifying crox yet.

andjo403 (Nov 08 2019 at 20:52, on Zulip):

ok then I will do something else

Wesley Wiser (Nov 08 2019 at 20:57, on Zulip):

I'll try to push it up by Monday or Tuesday so you can take a look and see what you think

Wesley Wiser (Nov 09 2019 at 16:55, on Zulip):

So I just realized my approach is probably bad. I was trying to add process_id as a field on measureme::Event but I don't think that's the right thing to do because we don't currently have JSON parsing code in measureme and we don't want to pull in any more dependencies than absolutely necessary in that crate.

I think the better thing to do is just do the parsing from crox where we already have a dependency on serde. Since I'm going to have to start over, feel free to take a shot at it. :slight_smile:

andjo403 (Nov 09 2019 at 16:57, on Zulip):

I was moving out the Event file to the tools lib right now :)

andjo403 (Nov 09 2019 at 16:59, on Zulip):

I can take a shot at it. but will maybe have the data from the header in profiling_data that I'm also moving

Wesley Wiser (Nov 09 2019 at 17:02, on Zulip):

Oh, that's even better!

Wesley Wiser (Nov 09 2019 at 17:02, on Zulip):

Splitting the library into readers and writers is a good idea

andjo403 (Nov 09 2019 at 17:08, on Zulip):

it seems like I need to add the tools_lib as a dev dependency in measureme due to the bench and tests uses the testing_common that is using event and the other structs that I moved

andjo403 (Nov 09 2019 at 17:08, on Zulip):

so we are back at needing a better name to tools_lib as @mw asked about before

Wesley Wiser (Nov 09 2019 at 17:12, on Zulip):

Not sure I'm totally understanding the problem at the moment but can we just move the tests to the tools_lib library?

andjo403 (Nov 09 2019 at 17:15, on Zulip):

yes it is possible to move the test and bench folder
I'm not sure I understand the problem yet it maybe is easier then I think I started like 20 min ago :)

Last update: Nov 17 2019 at 08:15UTC