Pith. sign in

REVIEW 5 major objections 4 minor 38 references

Exploiting Parallelism Opportunities with Deep Learning Frameworks

T0 review · 5 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 The average width of a deep learning model's graph determines the optimal CPU thread-pool setting, matching exhaustive search.

desk verdict A genuinely useful root-cause analysis of TF parallelism with a novel but under-specified width heuristic; the central speedup claim is plausible on Intel but not yet reproducible as written. read the letter →

arxiv 1908.04705 v2 pith:SCRLFMOL submitted 2019-08-13 cs.LG cs.DCcs.PFstat.ML

Yu Emma Wang , Carole-Jean Wu , Xiaodong Wang , Kim Hazelwood , David Brooks This is my paper · ORCID
classification cs.LGcs.DCcs.PFstat.ML
keywords deeplearningframeworksCPUperformancetuninginter-operatorparallelismintra-operatorthreadpoolsaveragemodelwidthTensorFlowprogrammabilitytax
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

This paper tries to establish that the performance gap between default deep-learning framework settings and the best possible CPU configuration is mostly a parallelism-scheduling problem, and that a model's computational graph contains enough information to close that gap without exhaustive search. The paper proposes a simple rule: set the number of inter-operator thread pools to the average width of the model's graph, then divide the physical cores evenly among those pools. On a held-out set of real-world models, this rule matches the speed of the globally optimal configuration on average and beats the settings recommended by Intel and TensorFlow by 1.29x and 1.34x. The point matters because CPU inference and training in datacenters currently leave a large, easy-to-reach speedup on the table, and the paper argues the fix does not require expert profiling.

What carries the argument

The load-bearing object is the average model width, a graph-level statistic defined as $\lfloor \text{total heavy operators} / \text{maximum layers} \rfloor$, where a heavy operator is a compute-intensive or embedding operator. This single number sets the number of inter-operator thread pools; the guideline then splits the system's physical cores evenly among those pools, giving the MKL threads and the framework's intra-op threads the same count so that one of each can share a physical core, one using FMA units and the other using other execution units. The machinery works by converting a five-dimensional tuning problem (scheduler, operator implementation, math library, thread pool library, parallelism mechanism) into a one-dimensional choice, justified by the observed balance between intra- and inter-operator parallelism.

What would settle it

Take a model whose graph has, say, three long independent branches but whose average width computes to 2, run an exhaustive sweep of pool counts and thread splits on a standard multicore CPU, and check whether the heuristic's choice is more than 5% slower than the sweep's optimum; such a case would refute the claimed match to the global optimum.

Watch

Extended reading notes

Core claim

The central discovery is that framework overhead in deep learning on CPUs--the so-called programmability tax--is dominated by how operators are scheduled and how their data is prepared, and that both can be controlled by one number: the number of inter-operator thread pools. From profiling traces, the paper shows that asynchronous scheduling helps only when a model's graph has branches that can run in parallel, and that the best pool count never exceeds the graph's maximum width. It then defines the average model width as $\lfloor \text{total heavy operators} / \text{maximum layers} \rfloor$ and claims that setting the pool count to this number, with MKL and intra-op threads each set to total physical cores divided by the pool count, achieves the same average performance as the global optimum found by exhaustive search over hundreds of thousands of configurations. The claim is supported on inference and training workloads, including recommendation and translation models, on a dual-socket server.

Load-bearing premise

The whole speedup rests on the average-model-width heuristic--$\lfloor \text{total heavy operators} / \text{maximum layers} \rfloor$--correctly predicting the best number of inter-op pools for models and CPUs it was not tuned on.

Editorial extensions

If this is right

  • Setting inter-op pools to the average model width instead of socket count yields 1.29x over Intel's and 1.34x over TensorFlow's recommended settings across the evaluated models.
  • The chosen setting matches globally optimal performance on average and stays within 95% of it in the worst case (Inception inference and SqueezeNet training).
  • Framework users running a single model per session should at least set inter-op pools to one rather than using TensorFlow's default of logical cores.
  • The same analysis applies to training as well as inference, since the training graph's extra gradient and sum-weight operators just change the effective width.

Reading between the lines

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

  • If the average-width rule transfers across architectures and framework versions as the paper suggests, the same heuristic could be packaged as a compiler or runtime pass that reads the graph and sets thread counts automatically, eliminating the plugin step.
  • Because the workload imbalance that motivates the rule is structural (branches of unequal size), dynamic thread-pool sizing that lets the scheduler assign threads per operator, which the paper notes as an opportunity, could beat any fixed split on graphs whose branch sizes vary widely.
  • The programmability tax numbers (1.3% to 63%) suggest that framework overhead will dominate as kernels get faster on CPUs and accelerators, so the scheduling lessons here are likely to matter more, not less, for future hardware.
  • One testable extension: compute the average width for large language models and compare against their observed optimal pool counts; if the rule holds there, the heuristic's scope extends well beyond the vision and recommendation models evaluated.
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

5 major / 4 minor

Summary. The paper is a measurement study of parallelism-related configuration knobs in CPU deep learning frameworks, focusing on TensorFlow v1.13 with MKL-DNN. It characterizes four design dimensions—operator scheduling (number of inter-op thread pools), operator implementation (intra-op threads), math/thread-pool libraries, and multi-socket placement—on Intel Skylake platforms. From these observations it distills a tuning guideline: set the number of inter-op pools p to the model's 'average width' (floor(total heavy operators / maximum layers)), and set intra-op and MKL threads to total physical cores divided by p. The authors integrate the rule into a TensorFlow plugin and evaluate it on a two-socket AWS instance, comparing against Intel and TensorFlow recommended settings and against an exhaustive search of 884,736 configurations. They report average speedups of 1.29x and 1.34x over the Intel and TensorFlow settings, respectively, and average performance equal to the global optimum, with a worst-case gap of 5%.

Significance. The practical contribution is strong if the result holds: the paper reduces an enormous configuration space to a single interpretable model-graph statistic, and it provides the strongest available evidence by evaluating on a platform and on recommendation/translation workloads not used in the guideline-development analysis, while also comparing to the global optimum via exhaustive search. The profiling methodology (top-down analysis, per-core traces, UPI bandwidth measurements) is careful, and the manuscript states that the code is open source, which aids reproducibility. The main caveats are that the average-width heuristic is not operationally defined in the manuscript, all performance numbers are point estimates, and the cross-architecture generalization is asserted rather than measured. If these are addressed, the paper would be a solid, useful systems contribution.

major comments (5)
  1. [§8 Definitions; Table 2] Section 8 defines average model width as floor(total heavy operators / maximum layers), but neither term is operationally defined. 'Heavy operator' is only exemplified as compute-intensive or embedding, and 'maximum layers' is ambiguous for graphs with branches, residuals, or embedding tables. Table 2 gives p values for seven models without per-model operator counts or graph-parsing rules, so an independent user cannot reproduce DenseNet=1, Wide&Deep=3, or Transformer=4 from the stated rule. Since the central speedup claim rests entirely on this quantity, the manuscript should specify the counting algorithm, the operator taxonomy, the parsed counts for all evaluated models, and ideally a script that computes p directly from a serialized graph.
  2. [§8 Evaluation; Figure 18] All reported speedups and the 'same performance as the global optimum' conclusion are based on point estimates. No error bars, number of repetitions, or variance statistics are reported for Figure 18 or the earlier scaling studies. On AWS bare-metal instances, run-to-run and neighbor interference can be non-negligible; the 1.29x/1.34x margins and the 95%-of-optimum worst case could change under variability. Please report means, standard deviations (or min/max), and repetition counts for at least the headline comparisons.
  3. [§8 Guidelines (first paragraph)] The statement that the guidelines are 'architecture-irrelevant' and 'can be applied to CPUs with different architectures including Intel, AMD and OpenPOWER' is not supported by the data. All experiments use Intel Skylake microarchitectures (i7-6700k and Platinum 8175M, one- and two-socket). The claim should be removed, restricted to a clearly labeled hypothesis, or tested on at least one non-Intel platform.
  4. [§3 vs §8; Figure 18] The paper states that non-vision models were held out for Section 8, but Figure 18 also includes the vision models DenseNet, ResNet, SqueezeNet, and InceptionV3. Please specify explicitly which models were used to derive the average-width rule and which were first evaluated at test time, and clarify whether the Table 2 p values for any model were chosen after seeing the exhaustive-search optimum on the evaluation platform. This distinction is necessary to assess how much of the reported 'match to global optimum' comes from the rule rather than from post hoc selection.
  5. [§4.1 vs §8] Section 4.1 identifies maximum graph width as the relevant inter-op parallelism bound and shows that the best pool count depends on batch size and on training versus inference, yet Section 8 switches to average width without derivation or sensitivity analysis. The paper should explain why average width is the right statistic, show how the predicted p changes with batch size and training/inference for the Table 2 models, and report how sensitive the final speedups are to p-1 and p+1.
minor comments (4)
  1. [Figure 1] The percentage labels on the stacked bars do not appear to sum to 100, and the legend makes it unclear which bar each percentage belongs to; please redraw with explicit axes and totals.
  2. [Section 1] The phrase 'another 25 ×' appears to be a typo (likely 2.5x), since the surrounding sentence says the whole-model improvement is 2.4x.
  3. [Section 8] The paper first attributes to TensorFlow the recommendation 'inter-op pools to the socket count' and later says 'TensorFlow naively sets all parameters...to the number of logical cores'; please reconcile the default TensorFlow behavior with the recommended setting from the cited performance guide.
  4. [Table 1] Table 1 omits memory capacity and logical-thread counts, which are useful for reproducing the hyperthreading analyses in Sections 5.2 and 8.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the tuning guideline is an empirically validated heuristic, not a derivation that reduces to its inputs.

full rationale

The central claim is an empirical performance result, not a mathematical derivation. Section 8 defines the rule p = floor(total heavy operators / maximum number of layers) independently of the measured optima, applies it to the models in Table 2, and then compares the resulting setting against a global optimum obtained by exhaustive search. The paper explicitly evaluates on held-out non-vision workloads (NCF, Transformer, Wide&Deep) and on the large.2 platform, which was not used in the analysis sections, so the comparison is not against the data used to form the rule. No equation in the paper equates the guideline's output to the measured optimum, and no fitted parameter is renamed as a prediction. The average-width metric is under-specified ('heavy operator' and 'maximum number of layers' lack an operational parser-level definition), which is a reproducibility/correctness concern rather than circularity; the same applies to the unsupported claim that the guidelines are architecture-irrelevant across AMD/OpenPOWER. There is no load-bearing self-citation or imported uniqueness theorem. Therefore no circular step can be exhibited from the text, and the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests mainly on the empirical validity of the average-width heuristic and on the transferability of Intel-specific measurements to other architectures. No fitting of continuous parameters is required, and no new physical or mathematical entities are introduced.

assumptions (3)
  • ad hoc to paper The optimal number of inter-op thread pools equals the average model width, defined as floor(total heavy operators / maximum layers).
    Introduced in Section 8 Definitions; no formal argument ties this metric to the optimal pool count; validation is empirical on a small set of models.
  • domain assumption Guidelines that work on Intel Skylake CPUs apply to other architectures (AMD, OpenPOWER) without modification.
    Section 8 states the guidelines are 'architecture-irrelevant'; all experiments use Intel Skylake variants, so this is unverified.
  • domain assumption The non-MKL fraction of execution time is a 'programmability tax' that can be largely optimized away with high-performance implementations.
    Section 5.2 estimates the tax as non-MKL time; some of this time (control flow, reshaping) is necessary, so the 'tax' overstates removable overhead.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Exploiting Parallelism Opportunities with Deep Learning Frameworks." pith.science (2026). https://pith.science/paper/SCRLFMOL

@misc{pith2026190804705,
  author       = {Pith},
  title        = {Pith review of: Exploiting Parallelism Opportunities with Deep Learning Frameworks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SCRLFMOL}},
  note         = {Machine review of arXiv:1908.04705}
}
read the original abstract

State-of-the-art machine learning frameworks support a wide variety of design features to enable a flexible machine learning programming interface and to ease the programmability burden on machine learning developers. Identifying and using a performance-optimal setting in feature-rich frameworks, however, involves a non-trivial amount of performance profiling efforts and often relies on domain-specific knowledge. This paper takes a deep dive into analyzing the performance impact of key design features in a machine learning framework and quantifies the role of parallelism. The observations and insights distill into a simple set of guidelines that one can use to achieve much higher training and inference speedup. Across a diverse set of real-world deep learning models, the evaluation results show that the proposed performance tuning guidelines outperform the Intel and TensorFlow recommended settings by 1.29x and 1.34x, respectively.

Figures

Figures reproduced from arXiv: 1908.04705 by the authors.

Figure 1
Figure 1. Time breakdown for Inception v3. Previous work have examined the performance of the modern DL frameworks and focused on cross-framework comparison [4, 22, 30]. These studies help machine learning model developers and engineers to make informed decisions about framework choices. However, there lacks in-depth, focused performance characterization studies that quantify performance impacts of key framework design featur… view at source ↗
Figure 2
Figure 2. An overview of the framework design features studied in this work. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Examples of (a) synchronous scheduling, (b) asynchronous scheduling, and (c) using one and four [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (15 more)
Figure 4
Figure 4. Figure 4: (Bar Chart) The speedup of using asynchronous scheduling over synchronous. (Table) The maximum [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: (a) Inception v2 architecture contains modules with four (b) and three (c) independent branches. Area [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Performance of Inception v2 with different numbers of inter-op pools and MKL threads per pool. Best [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Execution time breakdown of four cases. threads on the system is the product of the two. Hyperthreads are used when more than four threads are created. Exceeding eight threads is labeled over-threading because there are more software threads than hardware threads. (Sca…
Figure 8
Figure 8. Figure 8: Execution traces of three cases in Figure 7. Color-coded areas 1 and 2 correspond to the operators in [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Speedup from using 24 MKL threads instead of one. TensorFlow exhibits lower speedups than MKL. [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: Run-time breakdown for all CPU cores. Data preparation overhead causes the poor scalability in [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]
Figure 11
Figure 11. Figure 11: Run-time breakdown of TensorFlow workloads with 1 (left bar) and 24 (right bar) intra-op threads. [PITH_FULL_IMAGE:figures/full_fig_p013_11.png]
Figure 12
Figure 12. Figure 12: Run-time breakdown of all CPU cores. Intra-op threads parallelize the overhead in cores 24-47. [PITH_FULL_IMAGE:figures/full_fig_p013_12.png]
Figure 13
Figure 13. Figure 13: (a) Cycle breakdown (bottom axis) and IPC (top axis) for three libraries multiplying matrices of [PITH_FULL_IMAGE:figures/full_fig_p014_13.png]
Figure 14
Figure 14. Figure 14: Thread pool overhead, measured as time to run 10k micro tasks. Folly outperforms std::thread and [PITH_FULL_IMAGE:figures/full_fig_p015_14.png]
Figure 15
Figure 15. Figure 15: A two-socket platform speeds up ResNet-50 by 1.43 [PITH_FULL_IMAGE:figures/full_fig_p016_15.png]
Figure 16
Figure 16. Figure 16: (a) Speedup of a two-socket platform over one socket. (b) Measured peak UPI bandwidth consumption [PITH_FULL_IMAGE:figures/full_fig_p017_16.png]
Figure 17
Figure 17. Figure 17: Run-time breakdown of all CPU cores. critical paths and have similar sizes, as with multiple embedding operators in neural collaborative filtering (NCF). Performance and model parallelism mechanisms will be discussed in the next section. Model parallelism does not alw…
Figure 18
Figure 18. Figure 18: Performance using the recommended TensorFlow settings [ [PITH_FULL_IMAGE:figures/full_fig_p018_18.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 32 canonical work pages

  1. [1]

    Folly: Facebook Open-source Library

    2019. Folly: Facebook Open-source Library. https://github.com/facebook/folly

    work page 2019

  2. [2]

    Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, et al. 2016. TensorFlow: A System for Large-Scale Machine Learning. In OSDI, V ol. 16. 265–283. 19

    work page 2016

  3. [3]

    P Anju. 2018. Tips to Improve Performance for Popular Deep Learning Frameworks on CPUs. Intel Developer Zone (2018)

    work page 2018

  4. [4]

    Soheil Bahrampour, Naveen Ramakrishnan, Lukas Schott, and Mohak Shah. 2016. Comparative Study of Caffe, Neon, Theano, and Torch for Deep Learning. (2016)

    work page 2016

  5. [5]

    Jeff Bezanson, Alan Edelman, Stefan Karpinski, and Viral B Shah. 2017. Julia: A Fresh Approach to Numerical Computing. SIAM review 59, 1 (2017), 65–98

    work page 2017

  6. [6]

    Ashraf Bhuiyan, Mahmoud Abuzaina, Niranjan Hasabnis, Niroop Ammbashankar, Faijul Amin, Sheng Fu, and Bhavani Subramanian. [n.d.]. Improving TensorFlow Inference Performance on Intel Xeon Processors. Intel AI Blog ([n. d.])

    work page

  7. [7]

    Google AI Blog. 2019. Introducing GPipe, an Open Source Library for Efficiently Training Large-scale Neural Network Models. https:// ai.googleblog.com/ 2019/ 03/ introducing-gpipe-open-source-library.html(2019)

    work page 2019

  8. [8]

    Tianqi Chen, Mu Li, Yutian Li, Min Lin, Naiyan Wang, Minjie Wang, Tianjun Xiao, Bing Xu, Chiyuan Zhang, and Zheng Zhang. 2015. MXNet: A Flexible and Efficient Machine Learning Library for Heterogeneous Distributed Systems. arXiv preprint arXiv:1512.01274 (2015)

    arXiv 2015

Show all 38 references
  1. [9]

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, et al. 2018. {TVM}: An Automated end-to-end optimizing compiler for deep learning. In 13th {USENIX} Symposium on Operating Systems Design and Impl...

    2018

  2. [10]

    Heng-Tze Cheng. [n.d.]. Wide and Deep Learning: Better Together with TensorFlow. Google AI Blog ([n. d.]). https://ai.googleblog.com/2016/06/wide-deep-learning-better-together-with.html

    2016

  3. [11]

    Paul Covington, Jay Adams, and Emre Sargin. 2016. Deep Neural Networks for YouTube Recommendations. In Proceedings of the 10th ACM conference on recommender systems . ACM, 191–198

    2016

  4. [12]

    Eigen. 2019. Eigen Thread Pool. (2019). https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/ ThreadPool/

    2019

  5. [13]

    Assaf Eisenman, Maxim Naumov, Darryl Gardner, Misha Smelyanskiy, Sergey Pupyrev, Kim Hazelwood, Asaf Cidon, and Sachin Katti. 2018. Bandana: Using Non-V olatile Memory for Storing Deep Learning Models. arXiv preprint arXiv:1811.05922 (2018)

    2018 arXiv

  6. [14]

    Google. 2019. TensorFlow Performance Guide. https://docs.w3cub.com/tensorflow~guide/performance/performance_ guide/#general_best_practices. TensorFlow Documentation

    2019

  7. [15]

    Udit Gupta, Xiaodong Wang, Maxim Naumov, Carole-Jean Wu, Brandon Reagen, David Brooks, Bradford Cottel, Kim Hazelwood, Bill Jia, Hsien-Hsin S Lee, Andrey Malevich, Dheevatsa Mudigere, Mikhail Smelyanskiy, Liang Xiong, and Xuan Zhang. 2019. The Architectural Implications of Fac...

    2019 arXiv

  8. [16]

    Niranjan Hasabnis. 2018. Auto-Tuning TensorFlow Threading Model for CPU Backend. arXiv preprint arXiv:1812.01665 (2018)

    2018 arXiv

  9. [17]

    Kim Hazelwood, Sarah Bird, David Brooks, Soumith Chintala, Utku Diril, Dmytro Dzhulgakov, Mohamed Fawzy, Bill Jia, Yangqing Jia, Aditya Kalro, et al. 2018. Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective. In High Performance Computer Architecture ...

    2018

  10. [18]

    Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. 2016. Deep Residual Learning for Image Recognition. In Proceedings of the IEEE conference on Computer Vision and Pattern Recognition . 770–778

    2016

  11. [19]

    Xiangnan He, Lizi Liao, Hanwang Zhang, Liqiang Nie, Xia Hu, and Tat-Seng Chua. 2017. Neural Collaborative Filtering. In Proceedings of the 26th international conference on world wide web . International World Wide Web Conferences Steering Committee, 173–182

    2017

  12. [20]

    Gao Huang, Zhuang Liu, Laurens Van Der Maaten, and Kilian Q Weinberger. 2017. Densely Connected Convolutional Networks. In Proceedings of the IEEE conference on Computer Vision and Pattern Recognition . 4700–4708

    2017

  13. [21]

    Forrest N Iandola, Song Han, Matthew W Moskewicz, Khalid Ashraf, William J Dally, and Kurt Keutzer. 2016. SqueezeNet: AlexNet-Level Accuracy with 50x Fewer Parameters and <0.5 MB Model Size. arXiv preprint arXiv:1602.07360 (2016)

    2016 arXiv

  14. [22]

    Arpan Jain, Ammar Ahmad Awan, Quentin Anthony, Hari Subramoni, and Dhableswar K DK Panda. 2019. Performance characterization of dnn training using tensorflow and pytorch on modern clusters. In2019 IEEE International Conference on Cluster Computing (CLUSTER) . IEEE, 1–11

    2019

  15. [23]

    Yangqing Jia, Evan Shelhamer, Jeff Donahue, Sergey Karayev, Jonathan Long, Ross Girshick, Sergio Guadarrama, and Trevor Darrell. 2014. Caffe: Convolutional architecture for fast feature embedding. In Proceedings of the 22nd ACM international conference on Multimedia. ACM, 675–678

    2014

  16. [24]

    Nikhil Ketkar. 2017. Introduction to PyTorch. In Deep Learning with Python . Springer, 195–208

    2017

  17. [25]

    Primate Labs. 2019. GeekBench v4. https://www.geekbench.com/

    2019

  18. [26]

    Chris Lomont. 2011. Introduction to Intel Advanced Vector Extensions. Intel White Paper (2011), 1–21. 20

    2011

  19. [27]

    Mattson, V

    P. Mattson, V . J. Reddi, C. Cheng, C. Coleman, G. Diamos, D. Kanter, P. Micikevicius, D. Patterson, G. Schmuelling, H. Tang, G. Wei, and Carole-Jean Wu. 2020. MLPerf: An Industry Standard Benchmark Suite for Machine Learning Performance. IEEE Micro 40, 2 (2020), 8–16

    2020

  20. [28]

    Maxim Naumov, Dheevatsa Mudigere, Hao-Jun Michael Shi, Jianyu Huang, Narayanan Sundaraman, Jongsoo Park, Xiaodong Wang, Udit Gupta, Carole-Jean Wu, Alisson G Azzolini, Dmytro Dzhulgakov, Andrey Mallevich, Ilia Cherniavskii, Yinghai Lu, Raghuraman Krishnamoorthi, Ansha Yu, V ol...

    2019 arXiv

  21. [29]

    Vijay Janapa Reddi, Christine Cheng, David Kanter, Peter Mattson, Guenther Schmuelling, Carole-Jean Wu, Brian Anderson, Maximilien Breughe, Mark Charlebois, William Chou, et al. 2019. MLPerf inference benchmark. arXiv preprint arXiv:1911.02549 (2019)

    2019 arXiv

  22. [30]

    Shaohuai Shi, Qiang Wang, Pengfei Xu, and Xiaowen Chu. 2016. Benchmarking state-of-the-art deep learning software tools. In 2016 7th International Conference on Cloud Computing and Big Data (CCBD) . IEEE, 99–104

    2016

  23. [31]

    Akshitha Sriraman, Abhishek Dhanotia, and Thomas F Wenisch. 2019. SoftSKU: Optimizing Server Architectures for Microservice Diversity at Scale. In Proceedings of the 46th International Symposium on Computer Architecture . ACM, 513–526

    2019

  24. [32]

    Christian Szegedy, Wei Liu, Yangqing Jia, Pierre Sermanet, Scott Reed, Dragomir Anguelov, Dumitru Erhan, Vincent Vanhoucke, and Andrew Rabinovich. 2015. Going Deeper with Convolutions. In Proceedings of the IEEE conference on Computer Vision and Pattern Recognition. 1–9

    2015

  25. [33]

    Christian Szegedy, Vincent Vanhoucke, Sergey Ioffe, Jon Shlens, and Zbigniew Wojna. 2016. Rethinking the Inception Architecture for Computer Vision. In Proceedings of the IEEE conference on Computer Vision and Pattern Recognition . 2818–2826

    2016

  26. [34]

    Nicolas Vasilache, Oleksandr Zinenko, Theodoros Theodoridis, Priya Goyal, Zachary DeVito, William S Moses, Sven Verdoolaege, Andrew Adams, and Albert Cohen. 2018. Tensor Comprehensions: Framework-Agnostic High-Performance Machine Learning Abstractions. arXiv preprint arXiv:180...

    2018 arXiv

  27. [35]

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention Is All You Need. In Advances in Neural Information Processing Systems . 5998–6008

    2017

  28. [36]

    Carole-Jean Wu, David Brooks, Kevin Chen, Douglas Chen, Sy Choudhury, Marat Dukhan, Kim Hazelwood, Eldad Isaac, Yangqing Jia, Bill Jia, et al. 2019. Machine Learning at Facebook: Understanding Inference at the Edge. In 2019 IEEE International Symposium on High Performance Comp...

    2019

  29. [37]

    Saining Xie, Ross Girshick, Piotr Dollár, Zhuowen Tu, and Kaiming He. 2017. Aggregated Residual Transformations for Deep Neural Networks. In Proceedings of the IEEE conference on Computer Vision and Pattern Recognition . 1492–1500

    2017

  30. [38]

    Ahmad Yasin. 2014. A Top-Down Method for Performance Analysis and Counters Architecture. In 2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) . IEEE, 35–44. 21

    2014

Pith tools

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