diff --git a/src/talks/2024-04-12-UIC.erb b/src/talks/2024-04-12-UIC.erb
index df28bf8c..32ba6da5 100644
--- a/src/talks/2024-04-12-UIC.erb
+++ b/src/talks/2024-04-12-UIC.erb
@@ -221,7 +221,6 @@ end
Static Analysis
Microkernel Notebooks
-
Approximate Dependencies
Inter-Kernel Interop [Work In Progress]
@@ -413,6 +412,7 @@ end
"Bolt-on, Compact, and Rapid Program Slicing for Notebooks" (Shenkar et. al.; VLDB 2023)
+ (Similar ideas in Nodebook, etc...)
@@ -423,90 +423,186 @@ end
Does a cell need to be re-run based on these changes?
- What is the minimal set of inputs a cell needs to run?
-
Static required.
-
+
Which cell last wrote to a variable?
+
Dynamic sufficient.
-
Which cell last wrote to a variable?
-
Dynamic sufficient.
+
+
+ What is the minimal set of inputs a cell needs to run?
+
Static required.
+
- $$\{\;???\;\}$$
+
+ $\{\;???\;\}$ $\leftarrow \{\;z \rightarrow \textbf{@1}; x \rightarrow \textbf{@2}\;\}$
+
+
+ $\{\;\;\;\;\;\}$ $\leftarrow \{\;z \rightarrow \textbf{@1}; x \rightarrow \textbf{@2}\;\}$
+
<%=
notebook() do
nbcell("if z:\n y = x + 2", idx: 2)
end
%>
-
We need to be able to recover the notebook from any state.
+
We need to be able to recover the kernel to any state.
- Not same interpreter means:
- - No worrying about crashes
- - Portability / Resume at any point
- - Parallel execution
+
Why have only one kernel?
+
+
🤷
- Outline the data model:
-
- - Interpreter
- - "backend 'state database'"
- - Lazy-loading interpreter state
+ <%=
+ notebook() do
+ nbcell("x = expensive_initialization()")
+ nbcell("y = expensive_cloud_training1(x)")
+ nbcell("z = expensive_cloud_training2(x)")
+ nbcell("print( compare(y, z)")
+ end
+ %>
- If we have to have the ability to recover a state, does it have to be the same interpreter *version*?
+
- If we have to have the ability to recover a state, does it have to be the same language?
+
When is parallelism allowed?
+
When is a cell runnable?
- Cool things we can do if we lift the "state lives in the kernel" model
-
- - Deserialize program state into another interpreter
- - Graphical widgets for common tasks (data loading)
- - 1-3 slides on spreadsheets
-
-
-
-
- How to figure out dependencies
-
- 1. Run the code (exact, after the fact)
- 2. Static analysis (imprecise, incomplete)
- 3. Both!
+
Active if: first run or $\exists (x \rightarrow \textbf{@i}) \in \texttt{DynamicReads} : \texttt{InState}[x] \neq \textbf{@i}$
+
$\texttt{OutState} = \texttt{InState} + \{\;x \rightarrow \textbf{???}\;|\;\forall x \in \texttt{StaticWrites}\;\}$
+
+
Runnable
+
Active if: $\forall x \in \texttt{StaticReads} : \texttt{InState}[x] \neq \textbf{???}$
+
$\texttt{OutState} = \texttt{InState} + \{\;x \rightarrow \textbf{???}\;|\;\forall x \in \texttt{StaticWrites}\;\}$
+
+
Unknown
+
Active otherwise.
+
$\texttt{OutState} = \texttt{InState} + \{\;x \rightarrow \textbf{???}\;|\;\forall x \in \texttt{StaticWrites}\;\}$
+
-
+
+
+ "The Right Tool for the Job: Data-Centric Workflows in Vizier" (Kennedy et. al.; IEEE DEB 2022)
+
- State model. Review:
- - State needs to come *out* of the cell that created it
- - State needs to go *into* the cell that is about to consume it
+
+ 
+
+
+ 
+ 
+ 
+ 
+