Pith. sign in

REVIEW 3 major objections 8 minor 48 references

Recorder: Comprehensive Parallel I/O Tracing and Analysis

T0 review · 3 major / 8 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read The paper claims that full-parameter parallel I/O traces can be compressed by pattern recognition so that for typical strided I/O the structural trace size stays constant as processes and iterations grow, with about one-twelfth the space…

desk verdict The compression scheme is real and the tool looks useful, but the abstract's constant-trace-size claim is broader than what the evaluation actually shows. read the letter →

arxiv 2501.04654 v1 pith:CNAJNT74 submitted 2025-01-08 cs.DC cs.PF

Chen Wang , Izzet Yildirim , Hariharan Devarajan , Kathryn Mohror , Marc Snir This is my paper · ORCID
classification cs.DCcs.PF
keywords parallelI/Otracingpattern-recognitioncompressioncontext-freegrammarcallsignaturetableSequituralgorithmHPCanalysisinter-processtracescalability
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

Recorder tries to solve a practical wall in parallel I/O studies: capturing every I/O call with all its parameters usually produces traces that grow linearly with execution scale, which makes full-fidelity tracing unaffordable on large runs. The paper's central claim is that most parallel I/O is regular, and that regularity can be exploited: repeated call patterns are folded into a grammar, and call offsets that follow simple linear rules are encoded as compact pairs rather than stored one by one. As a result, for applications with typical strided parallel I/O, the stored grammar and signature tables stay constant in size as the number of processes and iterations grows, while only timestamps and indexing metadata keep growing linearly. The paper reports about 12x smaller traces than its predecessor on a real scientific simulation, and shows that the information needed for multi-layer call-chain analysis can be kept at overhead comparable to lightweight profiling. If right, this makes comprehensive, all-parameter I/O tracing practical at scales where it was previously out of reach.

What carries the argument

The carrying object is a per-process context-free grammar (CFG) plus a call signature table (CST). Each terminal symbol of the CFG stands for one unique call signature, which bundles function name, all parameters, thread ID, and call depth, and the CST maps signatures to terminals; the grammar is built online with a linear-time grammar induction algorithm, Sequitur. On top of this, I/O-pattern recognition encodes the offset of the $i$-th call as $i\cdot a + b$ into an $(a,b)$ pair when the linear rule holds, and another pass encodes offsets that are linear in process rank as $\mathrm{rank}\cdot a + b$, so identical call signatures reappear across ranks. A final global pass merges all CSTs, replaces per-rank MPI file handles with a group-wide file ID, and deduplicates identical CFGs, leaving three stored files: the merged CST, the unique CFGs, and a rank-to-CFG index. This mechanism is what lets all later analytics reconstruct the full call sequence from a small set of rules and signatures.

What would settle it

Run an I/O workload with data-dependent or random offsets at fixed per-process call count and increasing process count, and measure the grammar and call-signature-table file sizes. Constant size would support the general claim; linear growth would confirm that constant-size tracing is tied to linear offset patterns, the boundary the paper itself flags for machine-learning workloads.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that a tracing tool can capture every intercepted I/O call's full parameter set and still scale, because the trace's structural content, the per-process context-free grammars and the merged call-signature table, is redundant across iterations and ranks. Redundancy is removed in three passes: a grammar-building pass compresses recurring call sequences within one process; an I/O-pattern pass rewrites offsets that follow $i\cdot a + b$ into a compressed $(a,b)$ form so that loop iterations collapse; and a final global pass rewrites offsets that follow $\mathrm{rank}\cdot a + b$, replaces opaque file handles with group-wide IDs, merges all signature tables, and keeps only one copy of each identical grammar. Evaluations on a standard I/O benchmark and on a large-scale scientific simulation with independent and collective MPI-IO show the grammar and signature-table trace size remaining constant from 128 to 16,384 processes and from 100 to 1000 iterations in the independent-I/O case, with the collective-I/O trace size stabilizing once the number of aggregators stops increasing. Across full traces, the paper reports storing more information than its predecessor in about one-twelfth of the space, and runtime overhead that stays near a few percent even with aggressive checkpointing.

Load-bearing premise

The approach assumes that I/O call offsets are linear functions of the iteration index and of the process rank; when accesses are data-dependent or irregular, the pattern recognizer will not fire and the trace grows linearly with the number of unique calls.

Editorial extensions

If this is right

  • Strided, checkpoint, and collective I/O workloads can now be traced with all parameters at scale; the grammar portion of the trace is flat, and only timestamps and per-rank indexing grow linearly.
  • Complete call chains across high-level libraries, MPI-IO, and POSIX remain available for analysis, which is what lets the tool detect metadata-heavy and hybrid-communication behavior that coarse-grained tools miss.
  • Because the grammar representation is lossless in structure, the original per-call sequence can be regenerated from the compressed files, so smaller storage does not reduce analytical fidelity.
  • User-side choices follow directly: rolling checkpoints, or moving filenames outside the call signature, keep new output files from adding new grammars, as the paper suggests for checkpointing runs.

Reading between the lines

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

  • The linear-offset encoding could be generalized to offsets that are affine in multiple loop indices, such as $i\cdot a + j\cdot b + c$; the paper does not implement this, but its $(a,b)$ form suggests the natural extension.
  • Because timestamps and indexing metadata still grow linearly, the next scaling bottleneck for any workload is the timestamp stream; delta or entropy coding of timestamps would complement the grammar compression, a step the paper leaves implicit.
  • The same CFG-plus-signature scheme is not inherently I/O-specific: event traces from communication or scheduling with regular parameters could be compressed the same way, though the paper only targets I/O calls.
  • For irregular workloads the fallback is linear growth, so the practical reach of constant-size tracing depends on how many HPC applications have regular offset patterns; the paper's planned evaluation of machine-learning workloads will test exactly this boundary.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 8 minor

Summary. Recorder is an LD_PRELOAD-based parallel I/O tracing tool that intercepts calls across HDF5, NetCDF, PnetCDF, MPI-IO, MPI, POSIX, and CUDA layers, records full function parameters plus thread ID, call depth, and timestamps, and compresses the resulting event stream in two stages: per-process construction of a context-free grammar and call signature table using Sequitur, and intra-/inter-process I/O pattern recognition for offsets following linear functions of iteration count and rank, followed by a finalization-time inter-process merge that deduplicates CSTs and CFGs. The paper evaluates the system on IOR and FLASH (up to 16,384 processes), comparing space and time overhead with Recorder-old and Darshan. The main reported results are that the CFG+CST portion remains constant with process count for regular fixed-filename patterns, that full Recorder traces are about 12x smaller than Recorder-old's, and that runtime overhead is at most about 3% in the FLASH runs.

Significance. The core compression idea is valuable and the implementation appears substantial: automatic wrapper generation, support for multi-threaded and non-MPI programs, CUDA kernel tracing, and two output converters are concrete engineering contributions, and the FLASH evaluation at 16K processes is a strength. The 12x full-trace reduction over Recorder-old and the low time overhead are credible if the measurements in Section 5.3 are accurate. However, the headline property 'constant trace size regardless of execution scale' is not supported for the full trace and is contradicted by the paper's own iteration-scaling experiment. The manuscript needs to either implement and measure the filename-handling fixes it proposes, or carefully scope the claim to the CFG+CST subset for fixed-filename, linear-offset patterns. The authors' candid statement in Section 7 that workloads such as machine learning may not benefit is a credit to the paper and should be reflected in the abstract.

major comments (3)
  1. [Abstract; §5.2.1, Fig. 6 (right)] The central claim that 'Recorder achieves a constant trace size regardless of execution scale' is contradicted by Fig. 6 (right): when the number of iterations grows and FLASH writes a new plot/checkpoint file every 200 iterations, the CFG+CST trace size jumps at each new file because the filename is part of the call signature. Unique filenames for checkpoints and plot files are a normal parallel I/O pattern, so this is not an edge case. The remedies described in §5.2.1 (rolling checkpoints, excluding filenames from signatures, filename-pattern compression) are proposed but not implemented or measured; as written, the abstract's headline claim is therefore inaccurate and should be revised to state the conditions under which constant size actually holds.
  2. [§5.1, §5.2 vs. §5.3.1, Table 4] The trace-size metric used in Figs. 4-7 excludes the timestamp file and the CFG indexing file, as stated at the start of §5.1. When all Recorder output files are counted, §5.3.1 and Table 4 show the full trace roughly doubling as the process count doubles, with timestamps identified as the linear component. Hence even for fixed-filename, regular I/O patterns the complete trace grows linearly with execution scale; only the CFG+CST subset is constant. The paper should characterize the size of the complete trace in the abstract and in §3 rather than presenting the subset size as the trace size.
  3. [§3.2.1, §3.2.2, §5.2, §7] The generality of 'typical parallel I/O patterns' is not established. The I/O pattern recognition only handles offsets of the form i*a+b within a process and rank*a+b across processes, and the evaluation workloads (IOR and FLASH) produce exactly these linear patterns. Section 7 concedes that applications such as machine learning workloads may not benefit. The paper should either narrow the claims to linear-offset regular patterns or add a quantitative study of a workload with irregular or data-dependent access patterns.
minor comments (8)
  1. [§2.1] The text says 'Specially, in prologue, we capture...' and then later 'In prologue, we retrieve the exit time'; the second occurrence should refer to the epilogue.
  2. [§3.2.1] 'as the i-the call' should be 'as the i-th call'.
  3. [Abstract] 'scales linearly the application's execution scale' is missing 'with', and '12x less storage space' would be clearer as '1/12 of the storage space'.
  4. [§7] 'CUDA kernel inceptions' should be 'CUDA kernel interceptions', and 'proofing tool' should be 'profiling tool'.
  5. [Figure 7 caption] 'two different stripping configurations' should be 'striping configurations'.
  6. [§3.2.1 and §3.2.2] The detection rule for when a sequence of offsets is declared a pattern and when it is reset is underspecified; a short pseudocode block would make the algorithm reproducible.
  7. [§2.3] The statement that 'The converter creates a group of 64K records to generate 100MB of files' is unclear; please specify the row-group sizing and file-generation behavior.
  8. [§5.3.2] Time overhead is reported only at 4096 processes; reporting at least one larger scale would support the claim that overhead remains stable.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: compression detects patterns in observed call streams; the constant-size claim is narrower than the paper's own filename and timestamp data, but it is not a circular derivation.

full rationale

The paper's core derivation is self-contained. The compression algorithm reads intercepted I/O calls, builds per-process CFGs with Sequitur, and encodes offsets as linear functions (i*a+b intra-process, rank*a+b inter-process) whose coefficients are computed from adjacent observed calls. No parameter is fitted to a subset of data and then reported as a prediction of a closely related quantity; the trace size is the output being compressed, not a predicted target. The evaluation compares Recorder against external baselines (Darshan, Recorder-old, and no-tool runs), and the main compression mechanism is described in Sections 3.1 and 3.2 with examples. Citations to prior work by the same authors ([9], [19], [20]) provide the predecessor system and the recurring-pattern technique, but the load-bearing pattern recognition and inter-process compression are implemented and evaluated in this paper rather than imported as unverified premises. The abstract's 'constant trace size' claim is broader than what the paper's own data support: Section 5.2.1 shows the CFG+CST size jumping every 200 iterations when new filenames create new call signatures, with mitigations only proposed, and Section 5.3.1 states that the timestamp file grows linearly with the number of calls. That is an overstatement or internal inconsistency, not circularity, because the derivation chain does not reduce to its own inputs. No circular step can be exhibited with the required specificity, so the circularity score is 0.

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

The central compression claims rest on the assumption of linear offset patterns, the correctness of the Sequitur grammar construction, and the losslessness of the CFG/CST encoding. No numeric free parameters are fitted; the (a,b) pattern coefficients are computed from observed calls rather than tuned.

assumptions (3)
  • domain assumption I/O call offsets in typical HPC applications follow linear patterns within a process (i*a+b) and across processes (rank*a+b).
    Section 3.2.1 and 3.2.2 define the intra-process and inter-process I/O pattern recognition based on these linear forms; the constant-trace-size result depends on this. Section 7 states applications that do not benefit (e.g., machine learning) may see higher overhead and larger traces.
  • standard math The Sequitur algorithm correctly identifies the recurring structure in the terminal-symbol stream.
    Section 3.1 relies on the well-known linear-time Sequitur algorithm to build the CFG; the paper takes its correctness from the literature [21].
  • domain assumption Lossless reconstruction from CFG/CST is possible; the compressed grammar plus CST reproduces the exact call sequence with all parameters and ordering.
    Section 3.1 describes the CST mapping and the CFG starting rule, and the paper asserts the grammar allows full reconstruction, but no formal proof is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Recorder: Comprehensive Parallel I/O Tracing and Analysis." pith.science (2026). https://pith.science/paper/CNAJNT74

@misc{pith2026250104654,
  author       = {Pith},
  title        = {Pith review of: Recorder: Comprehensive Parallel I/O Tracing and Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CNAJNT74}},
  note         = {Machine review of arXiv:2501.04654}
}
read the original abstract

This paper presents Recorder, a parallel I/O tracing tool designed to capture comprehensive I/O information on HPC applications. Recorder traces I/O calls across various I/O layers, storing all function parameters for each captured call. The volume of stored information scales linearly the application's execution scale. To address this, we present a sophisticated pattern-recognition-based compression algorithm. This algorithm identifies and compresses recurring I/O patterns both within individual processes and across multiple processes, significantly reducing space and time overheads. We evaluate the proposed compression algorithm using I/O benchmarks and real-world applications, demonstrating that Recorder can store more information while requiring approximately 12x less storage space compared to its predecessor. Notably, for applications with typical parallel I/O patterns, Recorder achieves a constant trace size regardless of execution scale. Additionally, a comparison with the profiling tool Darshan shows that Recorder captures detailed I/O information without incurring substantial overhead. The richer data collected by Recorder enables new insights and facilitates more in-depth I/O studies, offering valuable contributions to the I/O research community.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 44 canonical work pages

  1. [1]

    IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008), 1–3951 (2018)

    IEEE Standard for Information Technology–Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7. IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008), 1–3951 (2018)

    work page 2018

  2. [2]

    In: Proceedings of the EDBT/ICDT 2011 Workshop on Array Databases

    Folk, M., Heber, G., Koziol, Q., Pourmal, E., Robinson, D.: An Overview of the HDF5 Technology Suite and Its Applications. In: Proceedings of the EDBT/ICDT 2011 Workshop on Array Databases. AD ’11 (2011)

    work page 2011

  3. [3]

    IEEE computer graphics and applications 10(4), 76–82 (1990)

    Rew, R., Davis, G.: NetCDF: An Interface for Scientific Data Access. IEEE computer graphics and applications 10(4), 76–82 (1990)

    work page 1990

  4. [4]

    Corbett, P., Feitelson, D., Fineberg, S., Hsu, Y., Nitzberg, B., Prost, J.-P., Snir, M., Traversat, B., Wong, P.: Overview Of The MPI-IO Parallel I/O Interface (1995)

    work page 1995

  5. [5]

    In: 2009 IEEE International Conference on Cluster Computing and Workshops, pp

    Carns, P., Latham, R., Ross, R., Iskra, K., Lang, S., Riley, K.: 24/7 Character- ization of Petascale I/O Workloads. In: 2009 IEEE International Conference on Cluster Computing and Workshops, pp. 1–10 (2009). IEEE

    work page 2009

  6. [6]

    In: PARCO, pp

    Shende, S., Malony, A.D., Spear, W., Schuchardt, K.: Characterizing I/O Performance Using the TAU Performance System. In: PARCO, pp. 647–655 (2011) 25

    work page 2011

  7. [7]

    In: 2012 SC Compan- ion: High Performance Computing, Networking Storage and Analysis, pp

    Kim, S.J., Son, S.W., Liao, W.-k., Kandemir, M., Thakur, R., Choudhary, A.: IOPin: Runtime Profiling of Parallel I/O in HPC Systems. In: 2012 SC Compan- ion: High Performance Computing, Networking Storage and Analysis, pp. 18–23 (2012). IEEE

    work page 2012

  8. [8]

    In: 2013 IEEE International Conference on Cluster Computing (CLUSTER), pp

    Luu, H., Behzad, B., Aydt, R., Winslett, M.: A Multi-level Approach for Understanding I/O Activity in HPC Applications. In: 2013 IEEE International Conference on Cluster Computing (CLUSTER), pp. 1–5 (2013). IEEE

    work page 2013

Show all 48 references
  1. [9]

    In: 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pp

    Wang, C., Sun, J., Snir, M., Mohror, K., Gonsiorowski, E.: Recorder 2.0: Effi- cient parallel I/O tracing and analysis. In: 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pp. 1–8 (2020). IEEE

    2020

  2. [10]

    Poliakoff, D., LeGendre, M.: Gotcha: An Function-Wrapping Interface for HPC Tools. In: Programming and Performance Visualization Tools: International Workshops, ESPT 2017 and VPA 2017, Denver, CO, USA, November 12 and 17, 2017, and ESPT 2018 and VPA 2018, Dallas, TX, USA, Nove...

    2019

  3. [11]

    In: 2005 International Conference on Parallel Processing Workshops (ICPPW’05), pp

    Katz, D.S., Jacob, J.C., Deelman, E., Kesselman, C., Singh, G., Su, M.-H., Berriman, G., Good, J., Laity, A., Prince, T.A.: A Comparison of Two Meth- ods for Building Astronomical Image Mosaics on a Grid. In: 2005 International Conference on Parallel Processing Workshops (ICPP...

    2005

  4. [12]

    Future Generation Computer Systems 46, 17–35 (2015)

    Deelman, E., Vahi, K., Juve, G., Rynge, M., Callaghan, S., Maechling, P.J., Mayani, R., Chen, W., Da Silva, R.F., Livny, M.,et al.: Pegasus, a Workflow Man- agement System for Science Automation. Future Generation Computer Systems 46, 17–35 (2015)

    2015

  5. [13]

    https://docs.nvidia.com/cupti/

    CUDA Profiling Tools Interface (2023). https://docs.nvidia.com/cupti/

    2023

  6. [14]

    https://www.zlib.net/

    Gailly, J.-l., Adler, M.: zlib A Massively Spiffy Yet Delicately Unobtrusive Compression Library (2017). https://www.zlib.net/

    2017

  7. [15]

    https://docs.google.com/document/d/ 1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview Accessed 2023-07-14

    Trace Event Format - Google Docs (2023). https://docs.google.com/document/d/ 1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview Accessed 2023-07-14

    2023

  8. [16]

    Practical Hadoop Ecosystem: A Definitive Guide to Hadoop-Related Frameworks and Tools, 325–335 (2016)

    Vohra, D., Vohra, D.: Apache parquet. Practical Hadoop Ecosystem: A Definitive Guide to Hadoop-Related Frameworks and Tools, 325–335 (2016)

    2016

  9. [17]

    https://perfetto.dev/docs/ analysis/trace-processor Accessed 2023-07-14

    Trace Processor - Perfetto Tracing Docs (2023). https://perfetto.dev/docs/ analysis/trace-processor Accessed 2023-07-14

    2023

  10. [18]

    In: BTW 2023, pp

    Rey, A., Freitag, M., Neumann, T.: Seamless Integration of Parquet Files into Data Processing. In: BTW 2023, pp. 235–258. Gesellschaft f¨ ur Informatik e.V., 26 Bonn (2023)

    2023

  11. [19]

    In: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, pp

    Wang, C., Balaji, P., Snir, M.: Pilgrim: Scalable and (near) Lossless MPI Tracing. In: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 1–14 (2021)

    2021

  12. [20]

    IEEE Transactions on Parallel and Distributed Systems 34(1), 123–140 (2022)

    Wang, C., Guo, Y., Balaji, P., Snir, M.: Near-lossless mpi tracing and proxy appli- cation autogeneration. IEEE Transactions on Parallel and Distributed Systems 34(1), 123–140 (2022)

    2022

  13. [21]

    Journal of Artificial Intelligence Research 7, 67–82 (1997)

    Nevill-Manning, C.G., Witten, I.H.: Identifying Hierarchical Structure in Sequences: A linear-time algorithm. Journal of Artificial Intelligence Research 7, 67–82 (1997)

    1997

  14. [22]

    In: 2023 IEEE International Conference on Cluster Computing Workshops (CLUSTER Workshops), pp

    Liem, R., Oeste, S., Lofstead, J., Kunkel, J.: Mango-IO: I/O Metrics Consis- tency Analysis. In: 2023 IEEE International Conference on Cluster Computing Workshops (CLUSTER Workshops), pp. 18–24. IEEE, Santa Fe, NM, USA (2023). https://doi.org/10.1109/CLUSTER Workshops61457.202...

    2023

  15. [23]

    In: 2020 IEEE 27th International Conference on High Performance Computing, Data, and Analytics (HiPC), pp

    Paul, A.K., Faaland, O., Moody, A., Gonsiorowski, E., Mohror, K., Butt, A.R.: Understanding HPC Application I/O Behavior Using System Level Statistics. In: 2020 IEEE 27th International Conference on High Performance Computing, Data, and Analytics (HiPC), pp. 202–211. IEEE, Pun...

    2020

  16. [24]

    In: 2022 IEEE International Conference on Cluster Computing (CLUSTER), pp

    Devarajan, H., Mohror, K.: Extracting and characterizing I/O behavior of HPC workloads. In: 2022 IEEE International Conference on Cluster Computing (CLUSTER), pp. 243–255. IEEE, Heidelberg, Germany (2022). https://doi.org/10.1109/CLUSTER51413.2022.00037 . https://ieeexplore.ie...

    2022

  17. [25]

    https://www.dask.org

    Dask — Scale the Python tools you love (2024). https://www.dask.org

    2024

  18. [26]

    In: Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis, pp

    Yildirim, I., Devarajan, H., Kougkas, A., Sun, X.-H., Mohror, K.: IOMax: Maxi- mizing Out-of-Core I/O Analysis Performance on HPC Systems. In: Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis, pp....

    2023

  19. [27]

    In: 2021 IEEE/ACM Sixth International Parallel Data Systems Workshop (PDSW), pp

    Yellapragada, S., Wang, C., Snir, M.: Verifying IO Synchronization from MPI Traces. In: 2021 IEEE/ACM Sixth International Parallel Data Systems Workshop (PDSW), pp. 41–46 (2021). IEEE

    2021

  20. [28]

    In: Proceedings of the 30th International Symposium on High-Performance Parallel and Distributed Computing

    Wang, C., Mohror, K., Snir, M.: File System Semantics Requirements of 27 HPC Applications. In: Proceedings of the 30th International Symposium on High-Performance Parallel and Distributed Computing. HPDC ’21, pp. 19–30. Association for Computing Machinery, New York, NY, USA (2...

    2021

  21. [29]

    IEEE Transactions on Parallel and Distributed Systems 35(6), 937–951 (2024) https://doi.org/10.1109/TPDS

    Wang, C., Mohror, K., Snir, M.: Formal Definitions and Performance Comparison of Consistency Models for Parallel File Systems. IEEE Transactions on Parallel and Distributed Systems 35(6), 937–951 (2024) https://doi.org/10.1109/TPDS. 2024.3391058

    2024

  22. [30]

    In: 2023 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pp

    Brim, M.J., Moody, A.T., Lim, S.-H., Miller, R., Boehm, S., Stanavige, C., Mohror, K.M., Oral, S.: UnifyFS: A User-level Shared File System for Unified Access to Distributed Local Storage. In: 2023 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pp. 2...

    2023

  23. [31]

    Nature 467(7319), 1061–1073 (2010) https://doi

    The 1000 Genomes Project Consortium: A map of human genome variation from population-scale sequencing. Nature 467(7319), 1061–1073 (2010) https://doi. org/10.1038/nature09534 . Accessed 2023-07-19

    2010 doi

  24. [32]

    International Journal of Computational Science and Engineering 4(2), 73 (2009) https://doi.org/10.1504/IJCSE.2009.026999

    Jacob, J.C., Katz, D.S., Berriman, G.B., Good, J.C., Laity, A.C., Deelman, E., Kesselman, C., Singh, G., Su, M.H., Prince, T.A., Williams, R.: Montage: a grid portal and software toolkit for science-grade astronomical image mosaicking. International Journal of Computational Sc...

    2009 arXiv

  25. [33]

    https://github.com/hpc-io/ior

    IOR: HPC IO Benchmark Repository (2023). https://github.com/hpc-io/ior

    2023

  26. [34]

    http://flash.uchicago.edu/site/ flashcode

    Flash Center for Computational Science (2019). http://flash.uchicago.edu/site/ flashcode

    2019

  27. [35]

    https://github.com/Tomas-M/iotop

    A Top Utility for IO (2023). https://github.com/Tomas-M/iotop

    2023

  28. [36]

    https://github.com/sysstat/ sysstat

    Performance Monitoring Tools for Linux (2023). https://github.com/sysstat/ sysstat

    2023

  29. [37]

    In: Tools for High Performance Computing 2011, pp

    Kn¨ upfer, A., R¨ ossel, C., Mey, D., Biersdorff, S., Diethelm, K., Eschweiler, D., Geimer, M., Gerndt, M., Lorenz, D., Malony, A., et al.: Score-P: A Joint Perfor- mance Measurement Run-Time Infrastructure for Periscope, Scalasca, TAU, and Vampir. In: Tools for High Performan...

    2012

  30. [38]

    In: 2010 IEEE International Symposium on Parallel & Distributed Processing (IPDPS), pp

    Uselton, A., Howison, M., Wright, N.J., Skinner, D., Keen, N., Shalf, J., Kar- avanic, K.L., Oliker, L.: Parallel I/O Performance: From Events to Ensembles. In: 2010 IEEE International Symposium on Parallel & Distributed Processing (IPDPS), pp. 1–11 (2010). IEEE 28

    2010

  31. [39]

    In: Proc

    Skinner, D.: Integrated Performance Monitoring: A Portable Profiling Infrastruc- ture for Parallel Applications. In: Proc. ISC2005: International Supercomputing Conference, Heidelberg, Germany (2005)

    2005

  32. [40]

    In: International Conference on Computational Science, pp

    Jurenz, M., Brendel, R., Kn¨ upfer, A., M¨ uller, M., Nagel, W.E.: Memory Alloca- tion Tracing with VampirTrace. In: International Conference on Computational Science, pp. 839–846 (2007). Springer

    2007

  33. [41]

    In: Proceedings of the 4th Annual Workshop on Petascale Data Storage, pp

    Vijayakumar, K., Mueller, F., Ma, X., Roth, P.C.: Scalable I/O Tracing and Analysis. In: Proceedings of the 4th Annual Workshop on Petascale Data Storage, pp. 26–31 (2009). ACM

    2009

  34. [42]

    Concurrency and Computation: Prac- tice and Experience 22(6), 702–719 (2010)

    Geimer, M., Wolf, F., Wylie, B.J., ´Abrah´ am, E., Becker, D., Mohr, B.: The scalasca performance toolset architecture. Concurrency and Computation: Prac- tice and Experience 22(6), 702–719 (2010)

    2010

  35. [43]

    In: International Conference on Computational Science, pp

    Kn¨ upfer, A., Brendel, R., Brunst, H., Mix, H., Nagel, W.E.: Introducing the Open Trace Format (OTF). In: International Conference on Computational Science, pp. 526–533 (2006). Springer

    2006

  36. [44]

    In: PARCO, vol

    Eschweiler, D., Wagner, M., Geimer, M., Kn¨ upfer, A., Nagel, W.E., Wolf, F.: Open Trace Format 2: The Next Generation of Scalable Trace Formats and Support Libraries. In: PARCO, vol. 22, pp. 481–490 (2011)

    2011

  37. [45]

    In: Proceedings of the 22nd European MPI Users’ Group Meeting, p

    Wagner, M., Doleschal, J., Kn¨ upfer, A.: MPI-focused Tracing with OTFX: An MPI-aware In-memory Event Tracing Extension to the Open Trace Format 2. In: Proceedings of the 22nd European MPI Users’ Group Meeting, p. 7 (2015). ACM

    2015

  38. [46]

    Procedia Computer Science 9, 1979–1987 (2012)

    Wagner, M., Knupfer, A., Nagel, W.E.: Enhanced Encoding Techniques for the Open Trace Format 2. Procedia Computer Science 9, 1979–1987 (2012)

    2012

  39. [47]

    In: Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis, pp

    Mohror, K., Karavanic, K.L.: Evaluating Similarity-based Trace Reduction Tech- niques for Scalable Performance Analysis. In: Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis, pp. 1–12 (2009)

    2009

  40. [48]

    In: Euro-Par 2013 Parallel Pro- cessing: 19th International Conference, Aachen, Germany, August 26-30, 2013

    Weber, M., Mohror, K., Schulz, M., Supinski, B.R., Brunst, H., Nagel, W.E.: Alignment-Based Metrics for Trace Comparison. In: Euro-Par 2013 Parallel Pro- cessing: 19th International Conference, Aachen, Germany, August 26-30, 2013. Proceedings 19, pp. 29–40 (2013). Springer 29

    2013

Pith tools

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