Pith. sign in

REVIEW 5 major objections 5 minor 25 references

Evaluating Efficiency and Novelty of LLM-Generated Code for Graph Analysis

T0 review · 5 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read This paper claims that Claude Sonnet 4 Extended currently leads frontier LLMs at generating efficient, ready-to-use C code for graph analysis, beating human-written triangle-counting baselines in speed.

desk verdict Worth publishing after the authors disclose the RTU test suite and threshold; the triangle-counting result is solid, but the head-to-head model ranking in the synthesis task is fragile. read the letter →

arxiv 2507.06463 v2 pith:EHVIQ4AZ submitted 2025-07-09 cs.SE

Atieh Barati Nia , Mohammad Dindoost , David A. Bader This is my paper
classification cs.SE
keywords LLM-generatedcodesoftwareperformanceengineeringtrianglecountinggraphalgorithmsCprogrammingalgorithmbenchmarkinglargelanguagemodels
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 asks whether large language models can write C code that is fast enough and memory-frugal enough for real graph-analysis workloads, not just code that passes unit tests. It benchmarks eight frontier models on two tasks: optimizing an existing triangle-counting implementation, and synthesizing routines for six graph problems from scratch inside an existing codebase. The central finding is that Claude Sonnet 4 Extended produced the most ready-to-use code, compiling and passing tests for 83% of the tasks, and generated a triangle-counting routine that runs faster than the human-written baselines on the largest tested graph. The paper also concludes that no model invented a fundamentally new algorithm; all successful solutions recombined known techniques such as forward counting, degree sorting, and hash-based intersection.

What carries the argument

The load-bearing object is an existing C triangle-counting benchmark: a collection of known human-written routines operating on graphs in compressed sparse row (CSR) format. Injecting LLM output into that existing source tree is what turns the task into a test of integration and performance rather than memorized snippets. The algorithmic workhorse in the fastest outputs is Forward Triangle Counting, in which vertices are sorted by degree and neighbor intersections are computed with hash tables; the fastest model variant paired that with tighter memory layout and cache locality. The paper's own scoring mechanism is the ready-to-use (RTU) gate—compilable, correct on a comprehensive test suite, and within an acceptable runtime threshold—plus a combined efficiency rate $1/(t m)$, where $t$ is runtime relative to the fastest implementation and $m$ is peak memory relative to the most memory-frugal one.

What would settle it

Run the same eight prompts on a public test suite of real-world graphs with pre-registered correctness cases and a stated runtime threshold; if a model other than Claude Sonnet 4 Extended posts the lowest combined runtime-memory score, or if Claude Sonnet 4 Extended fails any correctness case, the paper's central ranking claim is refuted.

Watch

Extended reading notes

Core claim

By placing each LLM inside an existing C benchmark for triangle counting and asking for the fastest integrable routine, the authors found that five of eight models produced correct triangle counts while three did not. On the largest test graph, Claude Sonnet 4 Extended's routine counted the same 101,930,789 triangles in 0.6245 seconds, beating the fastest human-written baseline at 0.7231 seconds and every other LLM. In the six-problem synthesis task, Claude Sonnet 4 Extended compiled, passed all tests, and ran within the time threshold for five of six problems, and its combined runtime-memory efficiency rate of 3.11 led all models. The paper therefore claims that contemporary LLMs are capable of high-performance C implementation work for established graph algorithms, while finding no evidence of transformative algorithmic invention.

Load-bearing premise

The rankings rest on an undisclosed correctness test suite and an unspecified 'acceptable runtime threshold,' and all performance measurements use only RMAT graphs, so if those do not represent the graphs a user cares about, the model ordering could change.

Editorial extensions

If this is right

  • Practitioners can treat Claude Sonnet 4 Extended as the current best frontier model for generating sequential C graph-analysis routines that drop into an existing codebase.
  • Correctness-only benchmarks measure too little; performance evaluation changes which model wins, so efficiency must be a first-class axis in LLM code evaluation.
  • LLM-generated C code can beat human baselines on a specific kernel, but only by recombining known algorithmic techniques, so expectations of algorithmic invention should be set aside for now.
  • The optimization approach shows that giving models the full source of existing implementations yields correct, integrable code from most frontier models, making LLMs usable as performance-engineering assistants.
  • The efficiency rate $1/(t m)$ provides a single score combining speed and memory; higher-scoring models often trade peak memory for runtime, as when Claude Sonnet 4 Extended used about 1.45 times the memory of the most frugal LLM while running about 27 times faster.

Reading between the lines

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

  • Editorial inference: because every timing uses RMAT graphs only, whose structure may favor cache-friendly forward counting, the speed ordering is likely workload-dependent; on lower-diameter or highly clustered graphs, the memory-heavy winners could lose to more frugal implementations.
  • Editorial inference: the undisclosed test suite and unspecified runtime threshold make the RTU percentages hard to reproduce; a public, per-problem test harness would let the community check whether the 83% figure survives contact with different input distributions.
  • Editorial inference: a natural next experiment is to measure novelty directly, for example by computing algorithmic-template or edit distance between each model's output and known published algorithms, turning the paper's 'no new algorithm' observation into a quantitative metric.
  • Editorial inference: model rankings in this space will decay quickly as new versions ship; the durable contribution is the methodology of embedding LLM output in a real C benchmark, not the specific winner.
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

5 major / 5 minor

Summary. The paper benchmarks eight state-of-the-art LLMs on generating efficient C implementations of graph-analysis routines. It uses two approaches: an optimization approach, where models are given an existing triangle-counting framework and asked to write a faster tc_fast() routine, and an algorithm-synthesis approach, where models implement graph algorithms (triangle counting, diameter, vertex connectivity, edge connectivity, clique number, chromatic number) from scratch. The authors define a Ready-To-Use (RTU) criterion (compilability, correctness on a test suite, and timeliness) and an efficiency rate 1/(t·m) summed over tasks, reporting that Claude Sonnet 4 Extended has the highest RTU rate (83%) and the highest composite efficiency rate (3.11), and that in the optimization approach Claude Extended and Gemini 2.5 Pro outperform human-written baselines on RMAT graphs. The paper also observes that no model invented a fundamentally new algorithm, with all solutions relying on known techniques such as Forward Triangle Counting.

Significance. If the results are reproducible and robust, this paper would be a valuable early contribution to LLM-assisted performance engineering in C, a niche largely neglected in favor of Python correctness benchmarks. The design choice to embed the model inside an existing codebase (Bader's framework) to reduce pretraining contamination is a strong methodological idea and could become a template for future evaluations. The concrete claim that Claude Sonnet 4 Extended beats human baselines in triangle counting on RMAT graphs is useful and falsifiable, and the authors' release of prompts, code, and measurement scripts supports reproducibility. However, the current manuscript's missing specification of the RTU test suite and timeliness threshold, the exclusive use of RMAT graphs, the absence of statistical error bars, and the unmeasured novelty promise all temper the significance of the findings until these gaps are addressed.

major comments (5)
  1. [Section III-B1] The Ready-To-Use (RTU) criterion is the linchpin of the paper's headline ranking, but its two key parameters are not specified. The text says code must pass 'all test cases in our comprehensive suite, which includes different types of graphs' and run within 'an acceptable runtime threshold,' yet the suite (number of graphs, families, sizes, generator settings, expected outputs) and the threshold value are never stated. Without these, Table I's 83% vs 50% RTU rates and Table II's efficiency totals cannot be audited or reproduced. This is not a cosmetic omission: in Table V, Claude Sonnet 4 Extended is the only model with an RTU implementation for Vertex Connectivity, which contributes 1.0 to its final score of 3.11; a single failure on an undisclosed test case would reduce its score to 2.11, below Grok 3 Think's 2.84 and changing the paper's central conclusion. The authors must disclose the full test suite and the timeliness threshold, preferably with the exact test harness.
  2. [Section II-A and Tables III-IV] All runtime and memory measurements are obtained exclusively on RMAT graphs (RMAT-6 through RMAT-18). The abstract and conclusions generalize to 'graph-analysis routines' and 'sparse graph algorithm code,' but a single synthetic generator with one degree-distribution model is a narrow empirical basis. Real-world graphs with different diameter, clustering, and degree correlations could rank the models differently. The authors should either include at least one additional graph family (e.g., a real-world network collection or a different synthetic model) or explicitly restrict all generalizations to RMAT-like graphs.
  3. [Section III-A and Table IV] The paper reports runtimes as averages over 10 executions but provides no variance, standard deviation, confidence intervals, or statistical comparison. The claim that Claude Sonnet 4 Extended outperforms the human-written Bader BFS baseline at RMAT-18 rests on a 13.6% difference (0.6245 s vs 0.7231 s), and the gap with Gemini 2.5 Pro is about 6.2% (0.6656 s). On a shared HPC node, such differences may be within measurement noise; the authors should report the per-execution distribution or at least standard deviations, and ideally a significance test.
  4. [Section III-B2 and Table II] The composite efficiency rate (rate = 1/(tm) for RTU tasks, 0 otherwise, summed across tasks) is introduced without justification or sensitivity analysis. The headline ordering is a direct consequence of this metric. For instance, the unique Vertex Connectivity win contributes 1.0 to Claude Extended's total, exactly as much as a near-optimal Diameter Finding implementation, even though the tasks differ substantially in difficulty. Alternative plausible metrics (e.g., equal weighting of time and memory, geometric mean, or a task-difficulty correction) could change the ranking. The authors should justify the metric and demonstrate that the top ranking is robust to reasonable alternative choices.
  5. [Title, Abstract, Section III-A] The manuscript promises an evaluation of the 'novelty' of LLM-generated code, but no novelty metric is defined or measured anywhere. In the optimization approach, models are given existing implementations and asked only to be faster; in the algorithm-synthesis approach, they implement standard algorithms. Table III's columns (Sort, Hash, FTC, BFS) classify whether known techniques were used, but that is not a novelty assessment. The conclusion that LLMs have not invented 'transformative algorithmic techniques' is therefore supported by design, not by measurement. The authors should either define an explicit novelty criterion (e.g., fraction of generated logic absent from the provided baselines, or a human expert's rating of algorithmic originality) or revise the title and abstract to remove the novelty claim.
minor comments (5)
  1. [Section II-B] The text says 'we selected the seven most frequently used frontier AI models' but then lists eight models; please correct the count.
  2. [Fig. 2 and Section III-B1] The prompt template in Fig. 2 lists five algorithms (triangle counting, diameter, vertex connectivity, edge connectivity, clique number), but Section III-B1 and Table V refer to six target graph problems including chromatic number. Either the prompt template should include chromatic number or the text should explain the discrepancy.
  3. [Table IV, RMAT-14/RMAT-15 rows for o3] The runtime jumps from 0.0314 s to 1.0949 s between RMAT-14 and RMAT-15, a 35x increase for a 2x increase in edge count; the discussion of o3's two helper functions in Section III-A suggests a size threshold, but since both RMAT-14 and RMAT-15 exceed 16,384 edges, the threshold alone does not explain the jump. Please verify or explain this data point.
  4. [Section II-C] The sentence 'The benchmark reports the average runtime over 10 executions for each implementation, providing statistical validity' overstates what an average provides; please replace it with a statement about mean runtime and add variance information.
  5. [Table III] Consider clarifying in the text that the incorrect triangle counts for Gemini 2.5 Flash (305,792,367), DeepSeek DeepThink (203,861,578), and Grok 3-Think (3,812,543) are 3x, 2x, and a different incorrect value relative to the correct count (101,930,789); the multiples suggest a failure to divide by a symmetry factor, an informative pattern for practitioners.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the model ranking is an empirical measurement under the authors' explicit metric; the sole self-citation (Bader's published benchmark) is prior external work and not load-bearing.

full rationale

Walk the claimed derivation chain: (i) RTU rates (Table I) come from compiling each model's code inside the provided framework and running a test suite; (ii) efficiency rates (Table II) are computed from the independently measured relative runtimes and memory footprints in Table V using the explicitly defined formula rate = 1/(tm) (Section III-B2); (iii) the triangle-counting comparison (Table IV) uses measured wall-clock times on RMAT graphs against human implementations from Bader [21], a prior published HPEC benchmark. None of these steps is circular in the rubric's sense: no input quantity is also the output (the rate is a closed-form normalization of measurements, not a parameter fitted to make Claude win), no fitted value is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no known result is renamed under new coordinates. The abstract's 'superior performance in ready-to-use code generation and efficiency' is the direct reading of the authors' own transparently defined metric applied to real measurements; this is benchmark construction, not a derivation, because the per-task pass/fail labels and the relative times/memory are independent data and the metric definition does not encode the conclusion. One self-citation exists: the framework and human baselines come from Bader [21],[24], who is an author of this paper. That citation is not load-bearing in a circular way: the framework is published prior work (HPEC 2023) whose code is externally available, and the human baselines' runtimes are measured on the same machine rather than asserted. Concerns raised in the paper's own methodology — the 'comprehensive suite' and 'acceptable runtime threshold' of Section III-B1 are undisclosed and all timing runs use only RMAT graphs — are reproducibility and construct-validity risks, not circularity, since nothing in those definitions presupposes the resulting model ordering. Because no specific reduction (Eq. X = Eq. Y by construction, or a fitted parameter reported as a prediction) can be exhibited by quotation, the honest finding is no significant circularity, with a minimal score reflecting the minor self-citation.

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

No new theoretical entities are introduced. The central ranking depends on two hand-chosen scoring thresholds (the RTU timeliness cutoff and the rate formula) plus the assumptions that RMAT graphs and the undisclosed test suite are representative.

free parameters (3)
  • RTU timeliness threshold = unspecified
    Section III-B1 defines timeliness as running within an acceptable runtime threshold without quantifying it; this threshold determines which implementations count as ready-to-use and therefore shapes every rate in Table II.
  • Efficiency rate weighting = 1/(t*m), 0 if no RTU
    Section III-B2 defines rate as a hand-chosen harmonic combination of relative time and memory; assigning zero to missing implementations rewards breadth over efficiency and drives the model ranking in Table II.
  • RMAT graph instance = not reported
    Only RMAT-generated graphs are used (Section II-A), and the generator seed or instance is not given; a different instance could change runtimes in Tables IV and V.
assumptions (3)
  • domain assumption RMAT synthetic graphs are representative of sparse graph workloads
    All experiments use RMAT-6 through RMAT-18; no other graph families appear, yet conclusions generalize to graph analysis.
  • domain assumption The undisclosed correctness test suite is comprehensive and correctly implemented
    RTU determination in Section III-B1 depends entirely on passing this suite, whose contents are not described.
  • domain assumption Averaging 10 runs without reporting variance is sufficient for runtime ranking
    Section II-C states only that runtimes are averaged over 10 executions; runs at RMAT-6 are tens of microseconds, and no error bars are given.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Evaluating Efficiency and Novelty of LLM-Generated Code for Graph Analysis." pith.science (2026). https://pith.science/paper/EHVIQ4AZ

@misc{pith2026250706463,
  author       = {Pith},
  title        = {Pith review of: Evaluating Efficiency and Novelty of LLM-Generated Code for Graph Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EHVIQ4AZ}},
  note         = {Machine review of arXiv:2507.06463}
}
read the original abstract

Large Language Models (LLMs) are increasingly used to automate software development, yet most prior evaluations focus on functional correctness or high-level languages such as Python. As one of the first systematic explorations of LLM-assisted software performance engineering, we present a comprehensive study of LLMs' ability to generate efficient C implementations of graph-analysis routines -- code that must satisfy stringent runtime and memory constraints. This emerging field of LLM-assisted algorithm engineering holds significant promise, as these models may possess the capability to design novel approaches that improve existing algorithms and their implementations. Eight state-of-the-art models (OpenAI ChatGPT o3 and o4-mini-high, Anthropic Claude 4 Sonnet and Sonnet Extended, Google Gemini 2.5 Flash and Pro, xAI Grok 3-Think, and DeepSeek DeepThink R1) are benchmarked using two distinct approaches. The first approach evaluates the ability of LLMs to generate algorithms that outperform existing benchmarks. The second approach assesses their capability to generate graph algorithms for integration into performance-critical systems. The results show that Claude Sonnet 4 Extended achieves superior performance in ready-to-use code generation and efficiency, outperforming human-written baselines in triangle counting. Although our findings demonstrate that contemporary LLMs excel in optimizing and integrating established algorithms, the potential for these models to eventually invent transformative algorithmic techniques represents a compelling frontier for future research. We provide prompts, generated code, and measurement scripts to promote reproducible research in this rapidly evolving domain. All of the source code is available on GitHub at https://github.com/Bader-Research/LLM-triangle-counting/.

Figures

Figures reproduced from arXiv: 2507.06463 by the authors.

Figure 2
Figure 2. The Second Prompt Structure Template. {ALGORITHM} is replaced by ”number of triangles”, ”diameter”, ”vertex connectivity”, ”edge connectiv￾ity”, and ”clique number” III. EXPERIMENTAL RESULTS The experiments were conducted on Wulver, NJIT’s high￾performance supercomputer, using a single core of an AMD EPYC 7753 CPU @ 2.45 GHz and 512 GB of RAM. A. Optimization Approach The evaluation demonstrates that while all model… view at source ↗
Figure 1
Figure 1. The First Prompt Structure Template. The Algorithm-Synthesis approach evaluates how well each model can generate efficient implementations of Triangle Counting, Diameter Finding, Vertex Connectivity, Edge Con￾nectivity, and Clique Number, when no prior code for these algorithms is provided. In this approach the provided C source contains the project’s core graph infrastructure; the algorithm implementations are deli… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

25 extracted references · 13 canonical work pages

  1. [1]

    A survey on evaluation of large language models,

    Y . Chang, X. Wang, J. Wang, Y . Wu, L. Yang, K. Zhu, H. Chen, X. Yi, C. Wang, Y . Wang et al. , “A survey on evaluation of large language models,” ACM Transactions on Intelligent Systems and Technology , vol. 15, no. 3, pp. 1–45, 2024

    2024

  2. [2]

    CodeT: Code generation with generated tests,

    B. Chen, F. Zhang, A. Nguyen, D. Zan, Z. Lin, J.-G. Lou, and W. Chen, “CodeT: Code generation with generated tests,” arXiv preprint arXiv:2207.10397, 2022

    arXiv 2022

  3. [3]

    Is your code generated by ChatGPT really correct? rigorous evaluation of large language models for code generation,

    J. Liu, C. S. Xia, Y . Wang, and L. Zhang, “Is your code generated by ChatGPT really correct? rigorous evaluation of large language models for code generation,”Advances in Neural Information Processing Systems, vol. 36, pp. 21 558–21 572, 2023

    work page 2023

  4. [4]

    CodeJudge: Evaluating code generation with large language models,

    W. Tong and T. Zhang, “CodeJudge: Evaluating code generation with large language models,” arXiv preprint arXiv:2410.02184 , 2024

    arXiv 2024

  5. [5]

    An empirical evaluation of GitHub copilot’s code suggestions,

    N. Nguyen and S. Nadi, “An empirical evaluation of GitHub copilot’s code suggestions,” ser. MSR ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 1–5

    work page 2022

  6. [6]

    Large language models of code fail at completing code with potential bugs,

    T. Dinh, J. Zhao, S. Tan, R. Negrinho, L. Lausen, S. Zha, and G. Karypis, “Large language models of code fail at completing code with potential bugs,” Advances in Neural Information Processing Systems , vol. 36, pp. 41 386–41 412, 2023

    work page 2023

  7. [7]

    Bugs in large language models generated code: An empirical study,

    F. Tambon, A. Moradi-Dakhel, A. Nikanjam, F. Khomh, M. C. Des- marais, and G. Antoniol, “Bugs in large language models generated code: An empirical study,” Empirical Software Engineering , vol. 30, no. 3, pp. 1–48, 2025

    work page 2025

  8. [8]

    Large language models and simple, stupid bugs,

    K. Jesse, T. Ahmed, P. T. Devanbu, and E. Morgan, “Large language models and simple, stupid bugs,” in 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR) . IEEE, 2023, pp. 563–575

    work page 2023

Show all 25 references
  1. [9]

    Evaluating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y . Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374 , 2021

    2021 arXiv

  2. [10]

    Program synthesis with large language models,

    J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le, and C. Sutton, “Program synthesis with large language models,” arXiv preprint arXiv:2108.07732 , 2021

    2021 arXiv

  3. [11]

    EffiBench: Benchmarking the efficiency of automatically generated code,

    D. Huang, Y . Qing, W. Shang, H. Cui, and J. Zhang, “EffiBench: Benchmarking the efficiency of automatically generated code,”Advances in Neural Information Processing Systems , vol. 37, pp. 11 506–11 544, 2024

    2024

  4. [12]

    How efficient is LLM-generated code? a rigorous & high-standard benchmark,

    R. Qiu, W. W. Zeng, J. Ezick, C. Lott, and H. Tong, “How efficient is LLM-generated code? a rigorous & high-standard benchmark,” arXiv preprint arXiv:2406.06647, 2024

    2024 arXiv

  5. [13]

    Comparing human and LLM generated code: The jury is still out!

    S. A. Licorish, A. Bajpai, C. Arora, F. Wang, and K. Tantithamthavorn, “Comparing human and LLM generated code: The jury is still out!” arXiv preprint arXiv:2501.16857 , 2025

    2025 arXiv

  6. [14]

    Mercury: A code efficiency benchmark for code large language models,

    M. Du, A. T. Luu, B. Ji, Q. Liu, and S.-K. Ng, “Mercury: A code efficiency benchmark for code large language models,” arXiv preprint arXiv:2402.07844, 2024

    2024 arXiv

  7. [15]

    On evaluating the efficiency of source code generated by LLMs,

    C. Niu, T. Zhang, C. Li, B. Luo, and V . Ng, “On evaluating the efficiency of source code generated by LLMs,” in Proceedings of the 2024 IEEE/ACM First International Conference on AI Foundation Models and Software Engineering , 2024, pp. 103–107

    2024

  8. [16]

    Evalu- ating language models for efficient code generation,

    J. Liu, S. Xie, J. Wang, Y . Wei, Y . Ding, and L. Zhang, “Evalu- ating language models for efficient code generation,” arXiv preprint arXiv:2408.06450, 2024

    2024 arXiv

  9. [17]

    FRANC: A lightweight framework for high-quality code generation,

    M. L. Siddiq, B. Casey, and J. C. Santos, “FRANC: A lightweight framework for high-quality code generation,” in2024 IEEE International Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2024, pp. 106–117

    2024

  10. [18]

    Evaluating the code quality of AI-assisted code generation tools: An empirical study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT,

    B. Yetis ¸tiren, I. ¨Ozsoy, M. Ayerdem, and E. T ¨uz¨un, “Evaluating the code quality of AI-assisted code generation tools: An empirical study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT,” arXiv preprint arXiv:2304.10778, 2023

    2023 arXiv

  11. [19]

    LLM4EFFI: Leveraging large language models to enhance code ef- ficiency and correctness,

    T. Ye, W. Huang, X. Zhang, T. Ma, P. Liu, J. Yin, and W. Wang, “LLM4EFFI: Leveraging large language models to enhance code ef- ficiency and correctness,” arXiv preprint arXiv:2502.18489 , 2025

    2025 arXiv

  12. [20]

    ECCO: Can we improve model-generated code efficiency without sacrificing functional correctness?

    S. Waghjale, V . Veerendranath, Z. Z. Wang, and D. Fried, “ECCO: Can we improve model-generated code efficiency without sacrificing functional correctness?” arXiv preprint arXiv:2407.14044 , 2024

    2024 arXiv

  13. [21]

    Fast triangle counting,

    D. A. Bader, “Fast triangle counting,” in 2023 IEEE High Performance Extreme Computing Conference (HPEC) . IEEE, 2023, pp. 1–6

    2023

  14. [22]

    Finding, counting and listing all triangles in large graphs, an experimental study,

    T. Schank and D. Wagner, “Finding, counting and listing all triangles in large graphs, an experimental study,” in International workshop on experimental and efficient algorithms . Springer, 2005, pp. 606–609

    2005

  15. [23]

    Algorithmic aspects of triangle-based network analysis,

    T. Schank, “Algorithmic aspects of triangle-based network analysis,” PhD dissertation, Karlsruhe Institute of Technology, 2007

    2007

  16. [24]

    Triangle counting through cover-edges,

    D. A. Bader, F. Li, A. Ganeshan, A. Gundogdu, J. Lew, O. A. Rodriguez, and Z. Du, “Triangle counting through cover-edges,” in 2023 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2023, pp. 1–7

    2023

  17. [25]

    R-MAT: A recursive model for graph mining,

    D. Chakrabarti, Y . Zhan, and C. Faloutsos, “R-MAT: A recursive model for graph mining,” in Proceedings of the 2004 SIAM International Conference on Data Mining . SIAM, 2004, pp. 442–446

    2004

Pith tools

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