Pith. sign in

REVIEW 4 major objections 4 minor 55 references

Extending TensorFlow's Semantics with Pipelined Execution

T0 review · 4 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read By tagging each data feed with batch metadata and placing buffering gates between graph stages, PTF gives a single TensorFlow instantiation the ability to process many concurrent, isolated requests, with credit-based flow control bounding…

desk verdict A working, open-source extension that gives TensorFlow multi-request pipelining, but the semantic guarantees are overclaimed and the headline 4x mixes pipelining with scale-out. read the letter →

arxiv 1908.09291 v1 pith:DTYOPTA2 submitted 2019-08-25 cs.DC

Sam Whitlock , James Larus , Edouard Bugnion This is my paper · ORCID
classification cs.DC
keywords pipelinedexecutionTensorFlowdataflowsemanticsbatchmultiplexingmetadatatagscredit-basedcontrolgenomealignmentcloudcomputingframeworks
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that TensorFlow's single-batch limitation is not inherent to its runtime: it can be lifted by partitioning an application graph into stateless stages, separated by gates that tag every feed with a batch ID and an arity. PTF implements this as a small patch that runs on an unmodified TensorFlow runtime and adds no client-side disambiguation. The result, if correct, makes TensorFlow usable as a persistent, multi-request cloud service for scientific pipelines. As evidence, the paper's genomics service PTFbio aligns and sorts 321 megabases per second on 20 machines, a 4x throughput increase over the non-pipelined baseline with only 0.13x added latency.

What carries the argument

The load-bearing mechanism is the gate. A gate is a buffering data structure inserted between two stages, each stage being an ordinary TensorFlow graph, and it interprets the metadata tensor attached to each feed to decide when batches open and close, when feeds can be regrouped or reordered, and whether an aggregate dequeue should combine several feeds into one and change the batch arity. Credit-based flow control, in which a downstream gate grants the upstream gate permission to open new batches, bounds memory use both within a machine and across machines.

What would settle it

Construct a PTF pipeline whose middle stage uses a data-dependent TensorFlow operation that does not preserve feed count, for example a condition that returns no output for some tensors, and check whether gates misattribute feeds across batches or the pipeline hangs. A simpler check is to run a batch whose arity is deliberately miscounted and observe whether gates open or close batches incorrectly.

Watch

Extended reading notes

Core claim

PTF's central claim is that concurrent, isolated processing of finite batches can be expressed inside TensorFlow's own dataflow semantics by carrying a metadata tensor alongside each feed. The metadata holds the batch ID and the batch arity, and gates between stages use it to route, buffer, reorder, and aggregate feeds while preserving the illusion that each batch runs alone. Because stages are stateless and TensorFlow guarantees exactly one output feed per input feed, gates can track batch progress locally without a central scheduler.

Load-bearing premise

The design assumes each stage graph is stateless and emits exactly one output feed for every input feed, so the batch ID and arity in the metadata stay correct as data moves through the pipeline; a stage that drops, duplicates, or splits feeds based on data values would break gate bookkeeping and deadlock the system.

Editorial extensions

If this is right

  • A single persistent TensorFlow application can serve a stream of finite batches concurrently, with each request isolated as if it ran alone.
  • Applications can overlap I/O and compute phases inside one runtime, eliminating the data-conversion cost of client-side request disambiguation.
  • Pipelines can be scaled out by replicating stages and local pipelines; PTFbio scales linearly until the merge phase saturates.
  • Fusing adjacent stages, such as align and sort, removes a full storage round trip, cutting aggregate I/O by 12 percent while keeping nodes balanced.
  • Existing TensorFlow nodes, the distributed runtime, and serialization mechanics remain usable, making the extension backward compatible.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The metadata scheme is essentially tagged-token dataflow embedded in TensorFlow; a natural extension would be to expose the tags to user stages for data-dependent routing, at the cost of weakening the statelessness guarantee.
  • The paper's credit-based flow control could be refined into end-to-end memory accounting across heterogeneous accelerators, possibly enabling tighter bounds than the current batch-counting credits.
  • A testable extension would apply the same stage-and-gate decomposition to machine-learning serving workloads with variable-length requests, comparing throughput and tail latency against client-side batching and queue-based workarounds.
  • Since gates require only exactly-once per-feed semantics, adding a per-feed sequence number to the metadata would let PTF absorb at-least-once delivery and feed-level replay, as the paper itself notes.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents Pipelined TensorFlow (PTF), a small-layer extension to TensorFlow that allows a single instantiated dataflow application to concurrently process multiple finite batches (requests) with isolated execution and bounded resources. PTF partitions a TensorFlow graph into stages separated by gates; each feed carries metadata (ID, arity), and gates use this metadata to track batch progress, regroup feeds, and implement credit-based flow control. The system is implemented as a patch to TensorFlow without modifying the core runtime, and it is demonstrated with PTFbio, a genome alignment and sorting service built on the Persona framework. The authors report a sustained alignment/sorting rate of 321 megabases/second across 20 machines and claim a 4x throughput improvement with only a 0.13x latency increase from pipelining.

Significance. If the guarantees are accepted, PTF is a useful step toward making TensorFlow usable as a general-purpose batch/cloud framework rather than a single-request machine-learning runtime. The idea of attaching metadata to feeds and pushing request multiplexing plus flow control into the runtime is original, and the system is implemented and released as open source, with a nontrivial bioinformatics application demonstrating I/O overlap and scale-out. The qualitative demonstration that concurrent isolated batches can flow through a single TensorFlow instantiation with bounded buffers is valuable and largely convincing. However, the correctness invariant underpinning batch tracking is not established for the full class of graphs the paper admits (control flow inside stages), and the headline 4x performance figure is confounded with scale-out and open-batch count, so the paper requires substantial revision before its central claims are fully supported.

major comments (4)
  1. [3.6, 7] The correctness of gates depends on the invariant that a stage maps one input feed to exactly one output feed with the same metadata ID and unchanged arity (§3.1, §3.6). The paper states this as a TensorFlow guarantee ('the stage's graph emits exactly one resulting feed after processing the input feed'), but TensorFlow does not guarantee this for arbitrary graphs, and §7 explicitly allows conditional and loop constructs inside a stage graph while §3.6 says any TensorFlow node may be used. A tf.cond or tf.while_loop can execute the stage's enqueue operation zero, one, or many times per input feed, and stateful nodes can break isolation; in such a stage the gates will never observe the expected arity, credits will not be returned, and the pipeline can deadlock or misattribute feeds. The paper must either restrict stage graphs to a provably feed-count-preserving, metadata-passthrough subset (e.g., plain dataflow with exactly one enqueue per dequeue and no control flow or stateful nodes), or implement and describe a runtime check/enforcement of this property. This is load-bearing because batch tracking is exactly what gates use to provide isolation.
  2. [6.2] The abstract and §6.2 claim that 'the pipelining mechanism of PTF can increase the throughput of a bioinformatics application by 4×,' but the 4x figure is obtained by comparing the maximal configuration (17 fused align-sort pipelines, 3 merge pipelines, 7 open batches) against a 1-align-sort-pipeline configuration (Fig. 4). This comparison simultaneously varies the number of hardware pipelines, the number of merge pipelines, and the number of open batches, so it does not isolate the effect of request pipelining. To support the stated claim, the paper should provide an ablation that varies only the number of open batches while holding the number and type of pipeline stages fixed, and it should report repeated runs with error bars; without such data, the 4x improvement is attributable to scale-out and raw concurrency rather than to PTF's pipelining semantics.
  3. [6.1-6.4] All quantitative results are reported as single values without error bars, confidence intervals, or the number of repetitions. Since §7 acknowledges that parameter tuning is essential ('A properly configured pipeline will be bound by the throughput of a hardware resource...'), the reader cannot tell whether the reported differences (e.g., 321 megabases/second, the 0.13x latency increase, or the scale-out curves in Fig. 6) are within run-to-run noise. The paper should at least report per-configuration variability and anchor the numbers against a non-pipelined baseline (e.g., the original Persona single-request application or TensorFlow with client-side request disambiguation), so that the claimed benefits are not only self-referential to a PTF configuration.
  4. [5, 6.4] The relationship between the 'baseline application' of Figure 2 and the configurations used in Figure 4 and Figure 6 is unclear. The baseline is described as three serial pipelines (align, sort, merge), but the 4x comparison in §6.2 is worded as an increase over a '1 fused align-sort pipeline configuration,' which appears to be neither the Figure 2 baseline nor a non-pipelined TensorFlow version. The paper should define exactly which configuration serves as the baseline for each reported speedup and explain whether the 12% I/O reduction in §6.4 is measured against the Figure 2 pipeline or against something else.
minor comments (4)
  1. [Figure 4 caption / 6.2] The caption of Figure 4 says each series has a fixed number of merge and align-sort pipelines, but the surrounding text says the figure shows 'an increasing number of open batches configured on the same application'; the caption should state explicitly which quantity is swept on each curve and at what values.
  2. [6.2, Figures 5 and 7] The number of open requests is reported as 6 in §6.2 ('With 6 open batches') but as 7 in the text and captions of Figures 5, 6, and 7; please reconcile this inconsistency.
  3. [3.2, 5, 6.2] The tuned parameters (number of open batches, number of align-sort pipelines, sort aggregation factor B, AGD chunk size) are mentioned across the paper, but there is no single table of values used for each experiment; adding such a table would make the evaluation reproducible.
  4. [Throughout] There are several typesetting issues, including missing spaces in 'aPTF application' (p.10) and 'the99th percentile' (§6.2), and the notation '1→N', 'N→1', 'B→1' in Figures 2 and 3 is never defined in the captions.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: PTF's claims are direct architectural and empirical results, and the disclosed same-group dependency on Persona is not load-bearing.

full rationale

PTF's contributions are architectural and empirical rather than derived predictions. The core mechanism—tagging each feed with (ID, arity), having gates track batch progress, and using credit-based flow control—is presented as the system design in Sections 3.1–3.3, not as a fitted parameter later renamed as a prediction. The aggregate-dequeue arity update, ceil(A/S), is arithmetic following from the definition of aggregation in Section 3.2, not a substantive derived result. The only same-group dependency is PTFbio's use of Persona [13], which is disclosed in Sections 5 and 8, but the paper's central claims—PTF runs on an unmodified TensorFlow runtime, enables concurrent isolated batches, and improves throughput—are demonstrated by direct measurements against alternative PTF configurations, not by citing Persona as evidence. The appeal to TensorFlow's exactly-once feed semantics in Section 3.6 is an external modeling citation from the TensorFlow authors, and the paper explicitly acknowledges reliance on it in Section 7; whether that guarantee holds for arbitrary stage graphs with control flow is a correctness or assumption concern, not circularity, because the paper's stage definition states the required stateless behavior. No self-definitional, fitted-input, uniqueness-imported, ansatz-smuggling, or renaming pattern appears in the paper's derivation chain.

Assumptions & free parameters 5 free parameters · 3 assumptions · 2 invented entities

The system rests on assumptions about TensorFlow's execution semantics and on a design constraint that stage graphs be stateless feed-preserving transformations. The evaluation introduces several hand-tuned configuration parameters (batch count, pipeline counts, grouping factor, chunk size) that are necessary to achieve the reported throughput, and these parameters are not derived from any theory.

free parameters (5)
  • number of open batches = 6 (maximal configuration)
    The evaluation varies the number of open batches (Figure 4) and chooses 6 because it saturates the merge pipelines; throughput gains from pipelining are measured at this tuned point.
  • number of fused align-sort pipelines = 17 vs 1 (4x throughput comparison)
    The 4x speedup is computed by comparing a configuration with 17 align-sort pipelines against one with a single align-sort pipeline, so the system configuration itself is a key experimental parameter.
  • number of merge pipelines = 3
    The paper states 3 merge pipelines in the maximal configuration; the balance between align and merge resources is hand-tuned.
  • aggregate grouping factor B for sort = 10 (224 sort operations from 2236 align operations)
    The aggregate dequeue before the sort stage groups B AGD chunks; the value 10 is used in the evaluation and affects sort granularity.
  • AGD chunk size = 100,000 records
    The input datasets are stored in Persona AGD format with a chunk size of 100,000, which affects parallelism and I/O granularity.
assumptions (3)
  • domain assumption TensorFlow's exactly-once delivery semantics guarantees that each gate receives a given feed only once and that a stage's graph emits exactly one output feed per input feed.
    Invoked in Section 3.6 to ensure the metadata ID/arity stays valid; if a feed could be duplicated or dropped, gate batch tracking would corrupt.
  • ad hoc to paper Each stage is a stateless transformation that does not modify the metadata tensor.
    Section 3.1 defines stages as stateless and the metadata as passed around unmodified; this is a design constraint on applications, not an inherent TensorFlow property.
  • domain assumption The application's computation can be expressed as a DAG partitioned into stages with only feed-level dependencies between stages.
    PTF's pipeline model requires partitioning the graph; iterative or client-driven control flow must be encoded inside stage graphs, limiting the class of supported applications (Section 3.6).
invented entities (2)
  • Gate independent evidence
    purpose: Buffers feeds between stages, interprets metadata to enforce batch isolation, ordering, aggregation, and credit-based flow control.
    Gates are new data structures implemented in the PTF patch; their behavior is demonstrated in the PTFbio evaluation (Figures 4-7).
  • Metadata tag (ID, arity) independent evidence
    purpose: Attached to each feed to identify which batch it belongs to and how many feeds the batch contains, enabling gates to track progress locally.
    The metadata tensor is the mechanism that makes concurrent batch isolation possible; its correctness is validated by the end-to-end application results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Extending TensorFlow's Semantics with Pipelined Execution." pith.science (2026). https://pith.science/paper/DTYOPTA2

@misc{pith2026190809291,
  author       = {Pith},
  title        = {Pith review of: Extending TensorFlow's Semantics with Pipelined Execution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DTYOPTA2}},
  note         = {Machine review of arXiv:1908.09291}
}
abstract

TensorFlow is a popular cloud computing framework that targets machine learning applications. It separates the specification of application logic (in a dataflow graph) from the execution of the logic. TensorFlow's native runtime executes the application with low overhead across a diverse set of hardware including CPUs, GPUs, and ASICs. Although the underlying dataflow engine supporting these features could be applied to computations beyond machine learning, certain design decisions limit this broader application, such as the inability for an application to differentiate between data items across concurrent requests. This paper introduces Pipelined TensorFlow (PTF), a system that extends TensorFlow's semantics to provide support for a broader variety of application logic. In particular, PTF supports applications that concurrently process finite batches of data on a single instantiation. PTF adds these semantics by partitioning the dataflow graph into a pipeline of smaller graphs and tagging each data item with metadata. These smaller graphs are separated by gates: new data structures in PTF that buffer data items between graphs and interpret the metadata to apply the new semantics. PTF's pipeline architecture executes on an unmodified TensorFlow runtime, maintaining compatibility with many existing TensorFlow library functions. Our evaluation shows that the pipelining mechanism of PTF can increase the throughput of a bioinformatics application by 4$\times$ while only increasing its latency by 0.13$\times$. This results in a sustained genome alignment and sorting rate of 321 megabases/second, using the compute and I/O resources of 20 computers.

Figures

Figures reproduced from arXiv: 1908.09291 by the authors.

Figure 1
Figure 1. The components of a stage: the logic, the adjacent gates with the corresponding enqueue and dequeue nodes in the stage, and the metadata. succession and processes them to completion entirely within the TensorFlow runtime. PTF is a careful addition of code to TensorFlow to en￾able pipelines of TensorFlow graphs to process concurrent batches within the same invocation of an application. This pipeline of independent Te… view at source ↗
Figure 2
Figure 2. A diagram of the baseline PTF application containing 3 local pipelines (align, sort, and merge), each of which have multiple stages that scale based on the underlying hardware. with a logical device (i.e., a label in the TensorFlow graph at￾tached to each node). The complete graph is then distributed to all machines in the cluster. Each machine is assigned a log￾ical device, corresponding to a local pipeline; upon s… view at source ↗
Figure 3
Figure 3. A full diagram of the Persona Align-Sort PTF pipeline, with the align and sort phases fused into a single pipeline. Both variants of the pipeline limit the number of open batches in the global and local pipelines via global and local credit links. The global credit links are end-to-end, limit￾ing the total number of open batches in the pipeline at any given time. Local credit links bound memory usage of a lo￾cal pip… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Latency vs. throughput for the fused align-sort application. Each series has a fixed number of local merge pipelines (1 to 3) and align-sort pipelines. Each series shows an increasing number of open batches configured on the same application, beginning from a single ba…
Figure 6
Figure 6. Figure 6: Scale-out behavior for the fused align-sort application for 1, 2, and 3 local merge pipelines, configured with 3, 5, and 7 open requests, respectively. 6.4 Benefits of Fusing Align and Sort The fused align-sort application enables the user to configure fewer machines a…
Figure 7
Figure 7. Figure 7: The aggregate steady-state behavior of both throughput and I/O for the fused align-sort application for a period of 5 minutes. The experiment uses 3 merge pipelines, 10 fused align-sort pipelines, and 7 open requests. This is a maximum￾throughput configuration for our …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 54 canonical work pages

  1. [1]

    Abadi, M., Isard, M., and Murray, D. G. A computational model for tensorflow: An introduction. In Proceedings of the 1st ACM SIG- PLAN International Workshop on Machine Learning and Programming Languages (New York, NY, USA, 2017), MAPL 2017, ACM, pp. 1–7

    work page 2017

  2. [2]

    MillWheel: Fault-Tolerant Stream Processing at Internet Scale

    Akidau, T., Balikov, A., Bekiroglu, K., Chernyak, S., Haberman, J., Lax, R., McVeety, S., Mills, D., Nordstrom, P., and Whittle, S. MillWheel: Fault-Tolerant Stream Processing at Internet Scale. PVLDB 6, 11 (2013), 1033–1044

    work page 2013

  3. [3]

    The Dataflow Model: A Practical Approach to Bal- ancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing

    Akidau, T., Bradshaw, R., Chambers, C., Chernyak, S., Fernández- Moctezuma, R., Lax, R., McVeety, S., Mills, D., Perry, F., Schmidt, E., and Whittle, S. The Dataflow Model: A Practical Approach to Bal- ancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. PVLDB 8, 12 (2015), 1792–1803

    work page 2015

  4. [4]

    Amazon Kinesis

    Amazon Web Services. Amazon Kinesis. https://aws.amazon.com/ kinesis/

    work page

  5. [5]

    Amdahl, G. M. Validity of the single processor approach to achieving large scale computing capabilities. In AFIPS Spring Joint Computing Conference (1967), pp. 483–485

    work page 1967

  6. [6]

    http://samza.apache.org/

    Apache Samza. http://samza.apache.org/

    work page

  7. [7]

    Apache Arrow

    Apache Software Foundation. Apache Arrow. https://arrow.apache. org/

    work page

  8. [8]

    Arvind, and Nikhil, R. S. Executing a Program on the MIT Tagged- Token Dataflow Architecture. IEEE Trans. Computers 39 , 3 (1990), 300–318

    work page 1990

Show all 55 references
  1. [9]

    S.Petascale Computational Systems

    Bell, G., Gray, J., and Szalay, A. S.Petascale Computational Systems. IEEE Computer 39, 1 (2006), 110–112

    2006

  2. [10]

    Bernard Marr . ThatâĂŹs Data Science: Air- bus Puts 10,000 Sensors in Every Single Wing! https://www.datasciencecentral.com/profiles/blogs/ that-s-data-science-airbus-puts-10-000-sensors-in-every-single

  3. [11]

    N., Kalcher, K., Huf, W., Na?el, C., and Moser, E

    Boubela, R. N., Kalcher, K., Huf, W., Na?el, C., and Moser, E. Big Data Approaches for the Analysis of Large-Scale fMRI Data Using Apache Spark and GPU Processing: A Demonstration on Resting-State fMRI Data from the Human Connectome Project. Front Neurosci 9 (2015), 492

    2015

  4. [12]

    Brewer, E. A. Kubernetes and the path to cloud native. In Proceedings of the 2015 ACM Symposium on Cloud Computing (SOCC) (2015), p. 167

    2015

  5. [13]

    Byma, S., Whitlock, S., Flueratoru, L., Tseng, E., Kozyrakis, C., Bugnion, E., and Larus, J. R. Persona: A High-Performance Bioinfor- matics Framework. In Proceedings of the 2017 USENIX Annual Technical Conference (ATC) (2017), pp. 153–165

    2017

  6. [14]

    Apache FlinkâĎć: Stream and Batch Processing in a Single Engine

    Carbone, P., Katsifodimos, A., Ewen, S., Markl, V., Haridi, S., and Tzoumas, K. Apache FlinkâĎć: Stream and Batch Processing in a Single Engine. IEEE Data Eng. Bull. 38 , 4 (2015), 28–38

    2015

  7. [15]

    Processing: What to record?https://cds.cern.ch/record/1997399, August 2012

    CERN. Processing: What to record?https://cds.cern.ch/record/1997399, August 2012

    2012

  8. [16]

    R., Bradshaw, R., and Weizenbaum, N

    Chambers, C., Raniwala, A., Perry, F., Adams, S., Henry, R. R., Bradshaw, R., and Weizenbaum, N. FlumeJava: easy, efficient data- parallel pipelines. In Proceedings of the ACM SIGPLAN 2010 Conference on Programming Language Design and Implementation (PLDI) (2010), pp. 363–375

    2010

  9. [17]

    Benchmarking Streaming Computation Engines: Storm, Flink and Spark Streaming

    Chintapalli, S., Dagit, D., Evans, B., Farivar, R., Graves, T., Holder- baugh, M., Liu, Z., Nusbaum, K., Patil, K., Peng, B., and Poulosky, P. Benchmarking Streaming Computation Engines: Storm, Flink and Spark Streaming. In Proceedings of the 30th IEEE International Sympo- siu...

    2016

  10. [18]

    De Fauw, J., Ledsam, J. R., Romera-Paredes, B., Nikolov, S., Toma- sev, N., Blackwell, S., Askham, H., Glorot, X., O’Donoghue, B., Visentin, D., van den Driessche, G., Lakshminarayanan, B., Meyer, C., Mackinder, F., Bouton, S., Ayoub, K., Chopra, R., King, D., Karthikesalingam...

    2018

  11. [19]

    MapReduce: simplified data processing on large clusters

    Dean, J., and Ghemawat, S. MapReduce: simplified data processing on large clusters. Commun. ACM 51, 1 (2008), 107–113

    2008

  12. [20]

    The MNIST Database of Handwritten Digit Images for Ma- chine Learning Research [Best of the Web]

    Deng, L. The MNIST Database of Handwritten Digit Images for Ma- chine Learning Research [Best of the Web]. IEEE Signal Process. Mag. 29, 6 (2012), 141–142

    2012

  13. [21]

    A., Fritzilas, E., Krusche, P., Kallberg, M., Moore, B

    Eberle, M. A., Fritzilas, E., Krusche, P., Kallberg, M., Moore, B. L., Bekritsky, M. A., Iqbal, Z., Chuang, H.-Y., Humphray, S. J., Halpern, A. L., Kruglyak, S., Margulies, E. H., McVean, G., and Bentley, D. R. A reference dataset of 5.4 million human variants validated by gen...

    2016

  14. [22]

    A., Ko, J., Swetter, S

    Esteva, A., Kuprel, B., Novoa, R. A., Ko, J., Swetter, S. M., Blau, H. M., and Thrun, S. Dermatologist-level classification of skin cancer with deep neural networks. Nature 542, 7639 (2017), 115–118

    2017

  15. [23]

    A Java vs

    Gherardi, L., Brugali, D., and Comotti, D. A Java vs. C++ Per- formance Evaluation: A 3D Modeling Benchmark. In Proceedings of the 2012 IEEE International Conference on Simulation, Modeling, and Programming for Autonomous Robots (SIMPAR) (2012), pp. 161–172

    2012

  16. [24]

    D., Katz, R

    Hindman, B., Konwinski, A., Zaharia, M., Ghodsi, A., Joseph, A. D., Katz, R. H., Shenker, S., and Stoica, I. Mesos: A Platform for Fine- Grained Resource Sharing in the Data Center. In Proceedings of the 8th Symposium on Networked Systems Design and Implementation (NSDI) (2011)

    2011

  17. [25]

    Loop Recognition in C++/Java/Go/Scala

    Hundt, R. Loop Recognition in C++/Java/Go/Scala. In Proceedings of Scala Days 2011 (2011)

    2011

  18. [26]

    Dryad: distributed data-parallel programs from sequential building blocks

    Isard, M., Budiu, M., Yu, Y., Birrell, A., and Fetterly, D. Dryad: distributed data-parallel programs from sequential building blocks. In Proceedings of the 2007 EuroSys Conference (2007), pp. 59–72

    2007

  19. [27]

    P., Young, C., Patil, N., Patterson, D

    Jouppi, N. P., Young, C., Patil, N., Patterson, D. A., Agrawal, G., Bajwa, R., Bates, S., Bhatia, S., Boden, N., Borchers, A., Boyle, R., luc Cantin, P., Chao, C., Clark, C., Coriell, J., Daley, M., Dau, M., Dean, J., Gelb, B., Ghaemmaghami, T. V., Gottipati, R., Gulland, W., ...

    2017

  20. [28]

    Accelerating Tensorflow with Apache Arrow on Spark

    Karau, H. Accelerating Tensorflow with Apache Arrow on Spark. Databricks Spark+AI Summit, 2018

    2018

  21. [29]

    M., Ramasamy, K., and Taneja, S

    Kulkarni, S., Bhagat, N., Fu, M., Kedigehalli, V., Kellogg, C., Mit- tal, S., Patel, J. M., Ramasamy, K., and Taneja, S. Twitter Heron: Stream Processing at Scale. In SIGMOD Conference (2015), pp. 239–250

    2015

  22. [30]

    Improving Python and Spark Performance and Interoper- ability with Apache Arrow

    Le Dem, J. Improving Python and Spark Performance and Interoper- ability with Apache Arrow. Databricks Spark+AI Summit, 2017

    2017

  23. [31]

    StreamScope: Continuous Reliable Distributed Processing of Big Data Streams

    Lin, W., Fan, H., Qian, Z., Xu, J., Yang, S., Zhou, J., and Zhou, L. StreamScope: Continuous Reliable Distributed Processing of Big Data Streams. In Proceedings of the 13th Symposium on Networked Systems Design and Implementation (NSDI) (2016), pp. 439–453

    2016

  24. [32]

    The Java Virtual Machine Specification

    Lindholm, T., and Yellin, F. The Java Virtual Machine Specification . Addison-Wesley, 1997

    1997

  25. [33]

    Litjens, G. J. S., Kooi, T., Bejnordi, B. E., Setio, A. A. A., Ciompi, F., Ghafoorian, M., van der Laak, J. A. W. M., van Ginneken, B., and Sánchez, C. I. A survey on deep learning in medical image analysis. Medical Image Analysis 42 (2017), 60–88. 13

    2017

  26. [34]

    Mardis, E. R. A decade’s perspective on dna sequencing technology. Nature 470 (02 2011), 198 EP –

    2011

  27. [35]

    Scalable, Fast Cloud Computing with Execution Templates

    Mashayekhi, O., Qu, H., Shah, C., and Levis, P. Scalable, Fast Cloud Computing with Execution Templates. CoRR abs/1606.01972 (2016)

    2016 arXiv

  28. [36]

    In Proceedings of the 2017 USENIX Annual Technical Conference (ATC) (2017), pp

    Mashayekhi, O., Qu, H., Shah, C., and Levis, P.Execution Templates: Caching Control Plane Decisions for Strong Scaling of Data Analytics. In Proceedings of the 2017 USENIX Annual Technical Conference (ATC) (2017), pp. 513–526

    2017

  29. [37]

    G., McSherry, F., Isaacs, R., Isard, M., Barham, P., and Abadi, M

    Murray, D. G., McSherry, F., Isaacs, R., Isard, M., Barham, P., and Abadi, M. Naiad: a timely dataflow system. In Proceedings of the 24th ACM Symposium on Operating Systems Principles (SOSP) (2013), pp. 439–455

    2013

  30. [38]

    A., Massie, M., Danford, T., Zhang, Z., Laserson, U., Yeksigian, C., Kottalam, J., Ahuja, A., Hammerbacher, J., Linder- man, M., Franklin, M

    Nothaft, F. A., Massie, M., Danford, T., Zhang, Z., Laserson, U., Yeksigian, C., Kottalam, J., Ahuja, A., Hammerbacher, J., Linder- man, M., Franklin, M. J., Joseph, A. D., and Patterson, D. A. Re- thinking Data-Intensive Science Using Scalable Analytics Systems. In SIGMOD Con...

    2015

  31. [39]

    J., Narayanan, D., Shanbhag, A., Palamuttam, R., Pirk, H., Schwarzkopf, M., Amarasinghe, S

    Palkar, S., Thomas, J. J., Narayanan, D., Shanbhag, A., Palamuttam, R., Pirk, H., Schwarzkopf, M., Amarasinghe, S. P., Madden, S., and Zaharia, M. Weld: Rethinking the Interface Between Data-Intensive Applications. CoRR abs/1709.06416 (2017)

    2017 arXiv

  32. [40]

    J., Zaremba, W., Cheung, V., Radford, A., and Chen, X

    Salimans, T., Goodfellow, I. J., Zaremba, W., Cheung, V., Radford, A., and Chen, X. Improved Techniques for Training GANs. InProceed- ings of the 2016 Annual Conference on Neural Information Processing Systems (NIPS) (2016), pp. 2226–2234

    2016

  33. [41]

    Big Data Spark Solution for Func- tional Magnetic Resonance Imaging

    Sarraf, S., and Ostadhashem, M. Big Data Spark Solution for Func- tional Magnetic Resonance Imaging. CoRR abs/1603.07064 (2016)

    2016 arXiv

  34. [42]

    E., Linderman, M

    Schadt, E. E., Linderman, M. D., Sorenson, J., Lee, L., and Nolan, G. P. Computational solutions to large-scale data management and analysis. 647

  35. [43]

    M., Kulkarni, S., Jackson, J., Gade, K., Fu, M., Donham, J., Bhagat, N., Mittal, S., and Ryaboy, D

    Toshniwal, A., Taneja, S., Shukla, A., Ramasamy, K., Patel, J. M., Kulkarni, S., Jackson, J., Gade, K., Fu, M., Donham, J., Bhagat, N., Mittal, S., and Ryaboy, D. V.Storm@twitter. In SIGMOD Conference (2014), pp. 147–156

    2014

  36. [44]

    A., Maier, D., Sheard, T., and Fegaras, L

    Tucker, P. A., Maier, D., Sheard, T., and Fegaras, L. Exploiting Punctuation Semantics in Continuous Data Streams.IEEE Trans. Knowl. Data Eng. 15, 3 (2003), 555–568

    2003

  37. [45]

    G.A Bridging Model for Parallel Computation

    V aliant, L. G.A Bridging Model for Parallel Computation. Commun. ACM 33, 8 (1990), 103–111

    1990

  38. [46]

    K., Murthy, A

    V avilapalli, V. K., Murthy, A. C., Douglas, C., Agarwal, S., Konar, M., Evans, R., Graves, T., Lowe, J., Shah, H., Seth, S., Saha, B., Curino, C., O’Malley, O., Radia, S., Reed, B., and Baldeschwieler, E. Apache Hadoop YARN: yet another resource negotiator. InProceedings of t...

    2013

  39. [47]

    R., Pardo, X

    Veiga, J., ExpÃşsito, R. R., Pardo, X. C., Taboada, G. L., and Touriño, J. Performance evaluation of big data frameworks for large-scale data analytics. In Proceedings of the 2016 IEEE Conference on Big Data (2016), pp. 424–431

    2016

  40. [48]

    Large-scale cluster management at Google with Borg

    Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., and Wilkes, J. Large-scale cluster management at Google with Borg. In Proceedings of the 2015 EuroSys Conference (2015), pp. 18:1–18:17

    2015

  41. [49]

    Reconstructing space-charge distorted ipm profiles with machine learning algorithms

    Vilsmeier, D., Sapinski, M., Singh, R., and Storey, J. Reconstructing space-charge distorted ipm profiles with machine learning algorithms. In 9th Int. Particle Accelerator Conf.(IPAC’18), Vancouver, BC, Canada, April 29-May 4, 2018 (2018), JACOW Publishing, Geneva, Switzerlan...

    2018

  42. [50]

    A., Brandt, S

    Weil, S. A., Brandt, S. A., Miller, E. L., Long, D. D. E., and Maltzahn, C. Ceph: A Scalable, High-Performance Distributed File System. In Proceedings of the 7th Symposium on Operating System Design and Implementation (OSDI) (2006), pp. 307–320

    2006

  43. [51]

    TensorFlowOnSpark

    Yahoo Inc. TensorFlowOnSpark. https://github.com/yahoo/ TensorFlowOnSpark

  44. [52]

    G., and Zheng, X

    Yu, Y., Abadi, M., Barham, P., Brevdo, E., Burrows, M., Davis, A., Dean, J., Ghemawat, S., Harley, T., Hawkins, P., Isard, M., Kudlur, M., Monga, R., Murray, D. G., and Zheng, X. Dynamic control flow in large-scale machine learning. In Proceedings of the 2018 EuroSys Conferenc...

    2018

  45. [53]

    J., Curtis, K., Fox, A., Patterson, D

    Zaharia, M., Bolosky, W. J., Curtis, K., Fox, A., Patterson, D. A., Shenker, S., Stoica, I., Karp, R. M., and Sittler, T. Faster and More Accurate Sequence Alignment with SNAP. CoRR abs/1111.5572 (2011)

    2011 arXiv

  46. [54]

    J., Shenker, S., and Stoica, I

    Zaharia, M., Chowdhury, M., Das, T., Dave, A., Ma, J., McCauly, M., Franklin, M. J., Shenker, S., and Stoica, I. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Com- puting. In Proceedings of the 9th Symposium on Networked Systems Design and ...

    2012

  47. [55]

    Discretized streams: fault-tolerant streaming computation at scale

    Zaharia, M., Das, T., Li, H., Hunter, T., Shenker, S., and Stoica, I. Discretized streams: fault-tolerant streaming computation at scale. In Proceedings of the 24th ACM Symposium on Operating Systems Principles (SOSP) (2013), pp. 423–438. 14

    2013

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.