← Advanced course and all videos

Video 12 of 53 · 4:50 · Execution, sharing and reuse

Shared nodes and actual reuse

In this video

  1. 0:00 · Introduction
  2. 0:17 · Give the shared node two consumers
  3. 1:12 · Core explanation
  4. 2:26 · Different roots remain different consumers
  5. 3:34 · Reuse has a lifetime
  6. 4:40 · Direct takeaways

Caption transcript

Show transcript
This overview explains how two branches can refer to one subexpression, and when execution can reuse its value. Shared storage alone does not guarantee that a later traversal or call avoids computing the same value again. Let S be A and B, used by two roots. The left root combines S with C using or; the right root combines S with D using exclusive-or. The same mathematical subexpression occurs in both roots. For this input, S is one. The left root computes one or zero, giving one. The right root computes one exclusive-or one, giving zero. Both consumers need the same intermediate one, but they produce different final answers. An evaluation memo can store S during this evaluation. The first consumer computes it; the second reads the stored value. Sharing the representation makes that reuse possible, while the evaluator and its memo scope determine whether the calculation is actually reused. Let S equal A AND B. Our rule is S AND C AND D, OR S AND E. The written rule contains two occurrences of S, one in each branch. A shared graph can replace them with one S node and two outgoing uses. At A B C D E equal 11011, S is one. The left branch is zero and the right branch is one, so the final OR is one. A second root, G, takes S exclusive-or E. At this assignment, G returns zero. Both roots can point to the same S identity. In a deliberately memoized traversal over both roots, S is computed once and its saved value serves each consumer. A shared node makes reuse possible. Whether an executor actually reuses it across roots or calls depends on its memo and lifecycle. The candidate companion checks a memoized teaching executor separately from repository node sharing; neither demonstrates a speedup. Return to the opening four-input, two-root graph: S equals A and B, L equals S or C, and R equals S exclusive-or D. The intervening five-input graph is separate. Here set A, B, C and D to zero, one, one and zero. Compute S as zero and one, giving zero. The left consumer combines it with C one using or, giving one. The right consumer combines it with D zero using exclusive-or, giving zero. Sharing an intermediate does not merge the two root operations or their answers. This case establishes a specific contrast. One shared value S=0. Root outputs are still distinct. Keep the input, intermediate values, and conclusion together when comparing it with the previous case. The calculated answer belongs to this complete assignment under the stated rule. A later call can reuse the same compiled graph while beginning with an empty evaluation memo. Representation reuse and cached numerical results have separate lifetimes. Inspect the actual API and execution scope before claiming that the second call skips all shared-node calculations. First reset the four-input graph to A one, B one, C zero and D one. Its shared value S is one. Now change only B to zero, keeping A, C and D fixed. S becomes zero, L becomes zero, and R becomes one. An old memo entry containing S one is invalid unless its identity includes the input context. Three counts can differ: unique nodes in the stored graph, evaluations during one call, and cache hits across calls. A drawing with one S node establishes structure. A claim about saved execution must also establish how the node values are managed. Identify the shared node and its consumers. State the memo and lifecycle boundary before counting saved work.