Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007, 2007 · paper · Computer science
Presents Dryad, a general-purpose distributed execution engine in which applications are dataflow graphs of sequential computation vertices linked by communication channels. Dryad handles scheduling, failure recovery and data transport, scaling from multi-core machines to data centers.
Checked: PDF from microsoft.com, fetched 4 Oct 2026. Page numbers are those of that PDF.
5 findings
Substance Sec 6.3: Q′ outputs totalling "153,703,445,725 Bytes" were "grouped into sets of at most 600 MBytes ... resulting in 217 T subgraphs" (Fig. 10: "each T may receive up to 600MB"), but 217 sets of at most 600 MB can hold no more than about 130 GB.
- p. 10 Section 6.3, right column
most 600 MBytes on the same local switch resulting in 217
- p. 10 Section 6.3, right column
that wrote a total of 153,703,445,725 Bytes.
- p. 11 Figure 10 caption and panel (b)
to 600MB
Only the authors can say what is right here.
Judge's note: Checked Sec 6.3 on p10 and Fig. 10 (caption and panel b showing 217 and 154 GB) on p11. 153.7e9/217 = 708 MB per T on average, and even with binary units that is 675 MiB, above the cap. Greedy overshoot cannot explain it, because the average Q′ output is about 14.8 MB. Grouping by switch could only increase the number of groups. The vertex count is internally consistent (10,405+217+450 = 11,072), so either the 600 MB cap or the byte total is off. Nothing in the text (Sec 5.2 or Figs 6-7) explains the gap. Only the authors can say which number is right.
Second check: another model agreed
Report a problem with this finding
Reference or label Related work names the system "Vulcan [22]", but reference [22] is Graefe, "Encapsulation of parallelism in the Volcano query processing system": the name should be Volcano.
- p. 12 Section 8, Parallel databases
e.g., Vulcan [22]
- p. 14 Reference [22]
Encapsulation of parallelism in the Volcano query processing system
- p. 12 Section 8, Parallel databases paragraph
Vulcan [22]
- p. 12 Section 8, Parallel databases
Vulcan [22], Gamma [17]
Judge's note: Page 12 reads 'e.g., Vulcan [22], Gamma [17]', and on page 14 the title of ref [22] names the Volcano system. No other reference matches 'Vulcan'. The mismatch is visible inside the paper itself.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [18] (DeWitt and Gray, CACM) is printed as "Communications of the ACM, 36(6), 1992"; the 1992 CACM volume is 35.
- p. 14 Reference [18]
Communications of the ACM, 36(6), 1992.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: CACM volume 35 is 1992 and DeWitt & Gray appeared in 35(6), June 1992. The page 14 image shows '36(6), 1992' as quoted.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [36] gives the venue as "(ASPLOS), Boston, MA, October 2006"; ASPLOS XII (Oct 2006) was held in San Jose, CA.
- p. 14 Reference [36]
(ASPLOS), Boston, MA, October 2006
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: ASPLOS XII in October 2006 was held in San Jose, CA, and Boston hosted ASPLOS XI in 2004. The page 14 image shows 'Boston, MA, October 2006' as quoted.
Second check: another model agreed
Report a problem with this finding
Reference or label References [9] ("...distributed systems. pages 178–187, New York, NY, USA, 1992") and [31] ("...parallel programming language. pages 167 – 177, Washington, D. C.") give no journal or proceedings name.
- p. 14 Reference [9]
systems. pages 178–187, New York, NY, USA, 1992.
- p. 14 Reference [31]
parallel programming language. pages 167 – 177,
Only the authors can say what is right here.
Judge's note: The page 14 images show both entries going straight from the title to the page numbers, with no venue in italics or plain type, while the other conference and journal entries name their venue. The missing venues cannot be supplied from the files.
Second check: another model agreed
Report a problem with this finding
4 minor (typos and the like; most checked by the judge only)
Wording Introduction says Section 6 gives "details of larger-scale experiments performed on clusters with thousands of computers" and claims performance shown "up to clusters consisting of thousands of computers", but the only large-scale experiment reported (Sec. 6.1/6.3) used "a cluster of around 1800 computers".
- p. 2 Introduction, contributions bullet 2
up to clusters con- sisting of thousands of computers
- p. 2 Introduction, last paragraph
larger-scale experiments performed on clusters with thou- sands of computers
- p. 9 Section 6.1 Hardware
a cluster of around 1800 computers
Judge's note: Checked p2 (both intro statements) and p9-10 (Sec 6.1 and 6.3). Only one large-scale experiment is reported, on a single cluster of around 1800 machines. Sec 6.3 mentions 'intermediate experiments' but gives no cluster size for them, and the Nebula remark in Sec 7.1 is not an experiment. 'Thousands' (plural clusters, ≥2000) overstates this a little, though it could be loose wording, so this is an observation only.
Second check: another model agreed
Report a problem with this finding
Wording "ugriz.bin" is given as "36-byte records, totaling 11.8 GBytes" for 354,254,163 records, but that product is 11.88 GiB (12.75 GB), while the other sizes in the paragraph (41.8, 31.3 GB, 655 KB, 649 KB) round correctly from their counts.
- p. 4 Section 2.1, first paragraph
has 36-byte records, totaling 11.8 GBytes
- p. 3 Section 2.1
has 354,254,163 records
Judge's note: Checked p3 (record counts) and p4 (file sizes). 354,254,163×36 = 12,753,149,868 B, which is 11.877 GiB and rounds to 11.9, not 11.8. neighbors.bin gives 2,803,165,372×16 = 41.77 GiB → 41.8, which matches, and that is rounding up, so truncation does not explain 11.8 either. ugriz.bin is said to be extracted from the index over all photoObjAll records, so there is no smaller subset to explain the figure. The discrepancy is small, so this is an observation.
Second check: another model agreed
Report a problem with this finding
Typo Ungrammatical "an input channel (which is be reported cleanly)": the word "be" is extra (should be "which is reported" or "which will be reported").
- p. 8 Section 5.1, first paragraph on page
(which is be reported cleanly)
Judge's note: The page 8 image shows the text exactly as quoted, so this is not an extraction artefact. It is a cosmetic slip.
Second check: none (judge only)
Report a problem with this finding
Typo Reference [24] reads "Nature, 440(23), March 23 2006": the issue field "(23)" repeats the day of the month and no pages are given.
- p. 14 Reference [24]
Nature, 440(23), March 23 2006.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: Nature vol. 440 issue 7083 is dated 23 March 2006. The page 14 image shows '440(23), March 23 2006'. That the issue number equals the day of the month suggests a slip, but the correct issue cannot be verified from the files.
Second check: none (judge only)