WEBVTT

1
00:00:00.000 --> 00:00:08.200
This overview explains how parallel materialization divides
output work and puts the results back in their proper places.

2
00:00:08.200 --> 00:00:15.698
Scheduling, transfers, cleanup, and worker startup can
outweigh the work saved by running pieces concurrently.

3
00:00:15.698 --> 00:00:15.700
Scheduling, transfers, cleanup, and worker startup can
outweigh the work saved by running pieces concurrently.

4
00:00:16.000 --> 00:00:19.333
Use abstract cost units for a small job.

5
00:00:19.333 --> 00:00:22.300
A serial worker takes four units.

6
00:00:22.300 --> 00:00:26.633
Splitting it evenly between two workers gives two units of computation per

7
00:00:26.633 --> 00:00:29.367
worker if they run concurrently.

8
00:00:29.367 --> 00:00:34.100
This is the useful work estimate before parallel overhead.

9
00:00:34.100 --> 00:00:39.767
Add one unit to split the work, one to dispatch it, two for the concurrent computation,

10
00:00:39.767 --> 00:00:42.700
one to merge, and one to deliver.

11
00:00:42.700 --> 00:00:47.433
The complete request takes six units in this illustrative schedule.

12
00:00:47.433 --> 00:00:52.600
Its computation stage improved, but the complete request is slower than the four-unit

13
00:00:52.600 --> 00:00:58.033
serial computation if comparable serial overhead is zero.

14
00:00:58.033 --> 00:01:03.300
For a larger job with one hundred units of serial compute, the same ideal split gives

15
00:01:03.300 --> 00:01:07.233
fifty units of compute plus four units of overhead.

16
00:01:07.233 --> 00:01:09.600
That totals fifty-four.

17
00:01:09.600 --> 00:01:14.800
The example explains why job size matters; it is not a measured scaling result or a

18
00:01:14.800 --> 00:01:18.695
guarantee of equal worker speed.

19
00:01:18.695 --> 00:01:18.700
guarantee of equal worker speed.

20
00:01:18.700 --> 00:01:25.400
Parallel materialization divides eligible output
work and assembles it deterministically.

21
00:01:25.400 --> 00:01:32.433
Scheduling, transfers, worker lifecycle and
merging remain part of a completed request.

22
00:01:32.433 --> 00:01:41.133
Imagine the four rows of our AB-by-CD grid arriving
in the order row three, row one, row zero, row two.

23
00:01:41.133 --> 00:01:49.867
Their identities allow assembly into rows 0111, 0111, 0111, 1000.

24
00:01:49.867 --> 00:01:53.767
Arrival order must not become matrix order.

25
00:01:53.767 --> 00:01:59.300
This is a conceptual scheduling example, not a measured parallel run.

26
00:01:59.300 --> 00:02:07.500
Current code guards work, handles shared-memory cleanup,
and waits for pending workers before releasing owner buffers.

27
00:02:07.500 --> 00:02:14.333
That repairs lifecycle behavior; it does not
turn a small example into a parallel win.

28
00:02:14.333 --> 00:02:20.255
Fresh-pool and reused-pool requests have different preparation costs.

29
00:02:20.255 --> 00:02:20.267
Fresh-pool and reused-pool requests have different preparation costs.

30
00:02:20.567 --> 00:02:25.567
Suppose one worker fails while another is still using shared input data.

31
00:02:25.567 --> 00:02:29.967
Receiving the first failure does not prove that the other worker has stopped.

32
00:02:29.967 --> 00:02:35.367
Its buffer remains live while that worker can still read or write it.

33
00:02:35.367 --> 00:02:40.933
A safe lifecycle coordinates cancellation or completion and waits until outstanding work

34
00:02:40.933 --> 00:02:43.300
no longer owns the data.

35
00:02:43.300 --> 00:02:46.700
Only then can shared storage be released.

36
00:02:46.700 --> 00:02:52.400
The exact API determines how this is done; the example states the ownership requirement

37
00:02:52.400 --> 00:02:57.167
rather than prescribing a universal cancellation call.

38
00:02:57.167 --> 00:03:02.867
A failed partial job must not be presented as a successful complete result.

39
00:03:02.867 --> 00:03:06.967
Cleanup and synchronization can also consume time.

40
00:03:06.967 --> 00:03:11.100
A useful parallel comparison declares whether that lifecycle work belongs

41
00:03:11.100 --> 00:03:14.133
to the measured boundary.

42
00:03:14.133 --> 00:03:14.136
Keep global indices attached to every chunk.

43
00:03:14.136 --> 00:03:18.133
Keep global indices attached to every chunk.

44
00:03:18.133 --> 00:03:25.300
Verify the assembled output and compare matched
worker lifecycles with all overhead included.