Stream: t-compiler

Topic: unified dataflow design meeting prep (Nov. 8)


ecstatic-morse (Nov 05 2019 at 18:47, on Zulip):

Oh, here's a link to the design doc. Skimming the code sections will help you get a feel for things if you don't want to read the whole thing:
https://hackmd.io/@39Qr_z9cQhasi25sGjmFnA/Skvd9rztS

ecstatic-morse (Nov 07 2019 at 21:08, on Zulip):

BTW, I mention both @nagisa's and @eddyb's work as prior art in the meeting agenda. If you're available for the meeting, it would be valuable to get your input. The MVP I discuss is much less ambitious than what either of you were working on, and I've not explored the issues that arise when trying to support arbitrary lattices.

Oliver Braunsdorf (Nov 08 2019 at 08:33, on Zulip):

Is the meeting open to everyone? If so, could you please tell me how I could join (or listen) to the meeting?

mw (Nov 08 2019 at 10:45, on Zulip):

@Oliver Braunsdorf the meeting will be here on Zulip

mw (Nov 08 2019 at 10:46, on Zulip):

so it's open to everyone :)

mw (Nov 08 2019 at 10:47, on Zulip):

https://calendar.google.com/event?action=TEMPLATE&tmeid=NWVxanM5MnVudW81ZmtrbDE5c2owb2IwY2IgNnU1cnJ0Y2U2bHJ0djA3cGZpM2RhbWdqdXNAZw&tmsrc=6u5rrtce6lrtv07pfi3damgjus%40group.calendar.google.com

Oliver Braunsdorf (Nov 08 2019 at 10:49, on Zulip):

Oh okay..I thought it would be some kind of phone or video conference :big_smile:
Thank you!

ecstatic-morse (Nov 08 2019 at 13:56, on Zulip):

BTW, I mention both @nagisa's and @eddyb's work as prior art in the meeting agenda. If either of you are available for the meeting, it would be valuable to get your input. The MVP I discuss is much less ambitious than what either of you were working on, and I've not explored the issues that arise when, e.g., trying to support arbitrary lattices.

@nagisa @eddyb

ecstatic-morse (Nov 08 2019 at 13:56, on Zulip):

(with real pings this time)

nikomatsakis (Nov 08 2019 at 14:47, on Zulip):

I'm skimming these docs now

nikomatsakis (Nov 08 2019 at 14:48, on Zulip):

Of course I wantd to do so before-hand

nikomatsakis (Nov 08 2019 at 14:48, on Zulip):

but of course I failed

nikomatsakis (Nov 08 2019 at 14:48, on Zulip):

one thing..well, I'm not sure if it matters. I guess it probably doesn't. I was going to say that polonius is using datafrog, which is itself a sort of dataflow framework, but one highly specialized to "sets" of things. In general, I expect that many of the consumers of the existing dataflow framework will move to polonius in any case.

ecstatic-morse (Nov 08 2019 at 14:54, on Zulip):

@nikomatsakis Don't let me interrupt your skimming, but I would guess datalog is more expressive than gen-kill sets (obvs) and lets you express your "transfer function" (not sure how this maps to datalog) as a high-level function. That may allow for better optimizations than allowing Fn(&mut State) as #64566 does.

nikomatsakis (Nov 08 2019 at 14:55, on Zulip):

datalog is all about sets of tuples, but it is lower-level in some sense

nikomatsakis (Nov 08 2019 at 14:55, on Zulip):

i.e., it doesn't hard-code the notion of a transfer function or a cfg

nikomatsakis (Nov 08 2019 at 14:56, on Zulip):

it is possible to extend from sets of tuples to more complex things

nikomatsakis (Nov 08 2019 at 14:56, on Zulip):

I guess the most direct question would be whether to port to datafrog instead of this new framework -- but I think I would wait on that until polonius has proven itself out

ecstatic-morse (Nov 08 2019 at 14:58, on Zulip):

Without knowing a lot about data{fr,l}og, I am guessing that we would ultimately want to keep a framework for bitvector problems as an optimization (it's pretty fast), but e.g. #64470 could use something at a higher level.

nikomatsakis (Nov 08 2019 at 14:58, on Zulip):

yes, plausible

ecstatic-morse (Nov 08 2019 at 15:07, on Zulip):

Okay,I'll give some background

nagisa (Nov 08 2019 at 20:01, on Zulip):

I’m here.

Last update: Nov 20 2019 at 01:10UTC