------------------------ HW8, due Monday, April 22: 30.3-4, 5 30.4-1, 2, 3 30.5-1, 2, 3, 4, 5, 6 284 exception: Omit two of these 11, if you like. ------------------------ Last reading: CLR Chapter 28 (or, better, 27 in 2nd edition) ------------------------ Idea for a last make-up meeting on Wednesday, May 1, 3:25 p.m.: One last (quiz-like) test Course evaluation forms ------------------------ Have I been receiving the HW postmortem reports? Please re-email me copies of them all, just to be sure! ------------------------ Easy in array, but *apparently* inherently sequential in linked list: 1. Ranking (trivial in array) 2. Summing (or any such associative operator) 3. Selection, or median finding (trivial in array) 4. Conversion to array Surprise: We *can* parallelize these well, provided the linked nodes are accessible in a (fairly-dense) array. Trick no. 1 (old): Path doubling (from everywhere, in parallel). O(log n) time, O(memsize * log n) work--nonoptimal Trick no. 2 (new): Reduce problem size first, by temporarily removing/abbreviating enough batches of independent nodes. (Did see this idea in array, but it's harder in linked list.) (Why the independence? To avoid ``contention''--see HW.) Supporting tricks: Coloring, to find independent sets Reversible compaction, to reduce memsize after Trick no. 2. Messiest obstacle to saving work: ``scheduling'' (One way to save work is to *design* for fewer processors; but we refer to *later* application of Brent's heuristic, to use a smaller number of processors to implement a *given* design.) ------------------------ Observation: Ranking is a sufficient key. No matter how we do it, we can then move to easier array setting. ------------------------ Understand the abbreviation and later restoration processes? Once you've abbreviated enough, you can afford a ``too-much-work'' approach. Useful scheduling aid available: After each abbreviation, compact shortened list into a shorter array, with aid of *array* parallel prefix computation in original memory. ------------------------ As usual, a probabilistic algorithm is simplest to design, but hardest to analyze. The text's: Design for n/log n processors. Assign log n nodes to each, contiguous only in the memory-array order. Each tries to splice out his nodes, one at a time, all the way until the list is trivial. On contention, decide who delays, based on a ``coin flip'' protocol: Proceed if ``head'' but next is not, insuring independence. Analysis: How long until list is empty? Maybe *forever*! (But see HW for a simple patch.) But what about *expectation*? Each *individual* ``work queue'': O(log n). Not sufficient for overall O(log n)--see why? More careful plan: Greatly increase the constant in the time target, c log n. Thus very high probability to finish individual queue (Chernoff). Thus still get high probability to finish *all* queues. Thus expectation not much more (with help from HW patch). ------------------------ Omitted in our reading, based on the same ``work-queue plan'': Much more complicated *deterministic* algorithm, with *worst-case* time O(log n). Much simpler, but almost as fast: ``Coloring'' approaches See how c-coloring can give a maximal independent set (MIS) in additional time O(c)? Trick to quickly get c-coloring for a small c: Start with trivial coloring *by memory addresses*. Repeatedly reduce the number of colors to 1+ceiling(lg c). (Stop when the number of colors gets down to a constant (6).) How do latter? Use new color that tells bit of node's old color that differs from that of next node. (Include both the bit and its position.) ------------------------ How many steps until down to 6? Note resemblance to ``lg* n''. Consider the following two operations: 1 + ceiling(lg x) and lg x . (Of course the former is always larger.) Lemma: Iterations of these operations remain within a constant of each other. (Thus the number of iterations of the coloring algorithm is indeed lg* n + O(1) .) Proof: Inductively, a constant such as 3 should work: 1 + ceiling(lg(y+3)) < lg y + 3 . Reason for ceiling(lg(y+3)) < lg y + 2: Adding 3 and rounding up to a power of 2 *passes* at most *one* power of 2 (except, perhaps, when y is already small). ------------------------ Get the idea how to employ this for some pretty good list ranking?