Pith. sign in

REVIEW 3 major objections 7 minor 76 references

CheckMate: LLM-Powered Approximate Intermittent Computing

T0 review · 3 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read CheckMate claims an LLM-driven pipeline can automatically approximate batteryless-IoT code, cutting power cycles by up to 60 percent while holding output error near 8 percent, without the manual tuning expert-guided tools require.

desk verdict A genuinely new integration of LLM-driven approximation with Bayesian tuning for intermittently powered IoT, but the reported accuracy figures are in-sample and the abstract overstates them. read the letter →

arxiv 2411.17732 v2 pith:RZ3NQUGQ submitted 2024-11-22 cs.DC

Abdur-Rahman Ibrahim Sayyid-Ali , Abdul Rafay , Muhammad Abdullah Soomro , Muhammad Hamad Alizai , Naveed Anwar Bhatti This is my paper · ORCID
classification cs.DC
keywords intermittentcomputingapproximatebatterylessIoTlargelanguagemodelsBayesianoptimizationpowercyclesenergyharvestingcodevalidation
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 claims that the labor-intensive step of adding approximate computing to batteryless IoT software can be fully automated by putting a large language model in the loop. CheckMate asks an LLM to choose which functions can tolerate error and to insert adjustable knobs that control the degree of approximation, then validates the modified code by compiling and running it, and finally uses Bayesian optimization in a cycle-accurate simulator to tune the knobs so that power cycles fall while error stays within a user-set bound. Across six IoT applications and five energy traces, the authors report power-cycle reductions of 15-60% with output errors in the 6-25% range, including a 60% reduction at about 8% error, and they report matching or beating a semi-automated expert-guided baseline without manual tuning. If correct, the contribution is a one-click route from ordinary C code to energy-optimized approximate code for intermittently powered devices. That would remove the expertise bottleneck that has kept approximation tied to specific applications and setups.

What carries the argument

The load-bearing mechanism is the adjustable knob: rather than letting the LLM hardcode approximation parameters, CheckMate prompts it to insert named variables, with ranges and step types, that control approximation levels in the code, for example a loop-perforation truncation factor. The knobs make approximation decisions executable and searchable: a Bayesian optimizer drives a cycle-accurate intermittent-computing simulator to vary the knobs and minimize the metric $e_m + c_r$, where $e_m$ is normalized output error and $c_r$ is the ratio of approximated to original power cycles, while a validation loop compiles and runs each proposed knob range to discard unsafe approximations. This separates what the LLM can reason about, where approximation is semantically acceptable and how to express it, from what it cannot measure, cycles, energy, and error, and it lets the optimizer tune out an approximation by setting its knob to a value that reproduces original behavior.

What would settle it

Run CheckMate on the same six applications but evaluate on held-out input and energy traces drawn from a different distribution than the traces used in Bayesian optimization; if the output error exceeds the user-set error bound or the reported 6-25% range, or the power-cycle reductions fall well below 15%, the central claim would be refuted.

Watch

Extended reading notes

Core claim

On the paper's own account, the central discovery is that a capable LLM, guided by a context-aware chain-of-thought prompt and a function call graph, can propose valid approximation opportunities for embedded code, and those proposals need not be final because an iterative compile-and-run validation loop repairs errors while tunable knobs let a Bayesian optimizer find the actual energy-accuracy trade-off. The measured claim is a 15-60% reduction in power cycles across Sobel edge detection, activity recognition, FFT, Boyer-Moore string search, link estimation, and bit counting, with output error between about 6% and 25% on the reported traces and a headline 60% reduction at about 8% loss. The same pipeline is claimed to meet or exceed the speedup of a semi-automated expert-guided framework on the shared Sobel and activity-recognition benchmarks while needing no expert input, and testbed runs replaying RF energy traces on real hardware track simulation results. A 17-participant user study is reported to cut average approximation time from about 14 minutes to under 3 minutes per task, supporting the usability half of the claim.

Load-bearing premise

The user-supplied input and energy traces, used both to tune the approximations and to report final error and power-cycle counts, must be representative of the inputs and energy conditions the device will actually see in the field.

Editorial extensions

If this is right

  • A developer can point the pipeline at an unmodified embedded C application and receive an approximated, tuned version without choosing functions or tuning parameters.
  • The reported 15-60% power-cycle reduction means the same computation finishes under scarcer and more erratic harvested energy, so batteryless devices can make progress where they previously stalled.
  • Context-aware LLM reasoning can exploit input-specific structure, such as shrinking a string-search bad-character table when traces do not use the full ASCII range, yielding cycle savings that generic approximation passes over.
  • Meeting a semi-automated expert-guided baseline on shared benchmarks suggests that automation costs little of the achievable energy-accuracy trade-off.
  • Because the output is ordinary C with knob variables, an optimized configuration can be re-tuned for another board, capacitor size, or energy trace without re-running the LLM reasoning steps.

Reading between the lines

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

  • An extension the paper does not make: held-out trace evaluation. Because the same traces tune the knobs and report final error, deployment error under a different input distribution could exceed the reported 6-25% bounds.
  • The same division of labor should transfer to any accuracy-tolerant embedded workload with a cycle- or energy-accurate simulator, not only checkpointed intermittent systems.
  • Because the knobs are runtime variables, a future adaptive controller could adjust them online from energy availability, turning the offline trade-off into a dynamic policy.
  • If local open-source LLMs reach parity with commercial APIs, the privacy concern of sending proprietary code to an external model disappears without changing the pipeline.
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 / 7 minor

Summary. The paper introduces CheckMate, an automated framework for approximate intermittent computing on batteryless IoT devices. CheckMate uses an LLM to identify approximation opportunities, generate code with tunable 'knobs', and then applies Bayesian optimization over those knobs in the Fused cycle-accurate simulator to minimize an objective that combines output error and power-cycle count. The evaluation covers six applications, five RF energy traces, simulation and an MSP430 testbed, a comparison with the ACCEPT framework, and a 17-participant user study. The claimed results are power-cycle reductions of 15–60% with output errors in the 6–25% range, and an abstract-level claim of 'accuracy loss of just 8%'.

Significance. If the accuracy and cycle-reduction claims hold under deployment-like conditions, CheckMate would be a meaningful step toward fully automated approximate computing for transiently powered systems, replacing manual expert effort. The paper has several strengths: the source code is open, the workflow is described in enough detail to reproduce, the appendix includes the exact LLM prompts, and the MSP430 testbed provides an independent, hardware-based check of the power-cycle-reduction results. The Bayesian-optimization loop and the testbed measurement of cycle counts are separate grounding that partially de-risks the energy claims. However, the accuracy half of the central claim rests on an in-sample evaluation: the same user-provided traces are used for optimization and for reporting final error rates, with no held-out traces or distribution-shift analysis. This makes the generalization of the reported error rates the main point of uncertainty.

major comments (3)
  1. [Section 3.3 and Section 4.2] The final error rates are computed on the same user-provided input traces that the Bayesian optimizer minimized over in Eq. (1). Section 3.3 states that both em and cr are evaluated on user traces, and Section 4.2 reports results on those same traces (Figure 8, Table 3). No held-out traces or distribution-shift analysis is presented, so every reported accuracy figure is an in-sample optimum of the very objective that was optimized. This is load-bearing because the framework's value proposition is that it meets user error bounds in deployment, not only on the developer's tuning inputs. The Boyer-Moore experiment in Section 4.2 makes the risk concrete: when the input trace is withheld from the LLM, the resulting approximation changes and the cycle savings drop from 31% to 10%, demonstrating trace-conditioned behavior. Please add an evaluation on held-out input traces (for example, cross-validating over the five RF traces and varying input data), or explicitly restrict the accuracy claims to the tuning set and explain how a user would validate the chosen knob values on their own deployment inputs.
  2. [Abstract, Section 1, Table 3] The abstract claims 'accuracy loss of just 8%', while Section 1 and the benefits paragraph state that error rates are 'within the range of 6–25%'. Table 3 reports Bit Count errors of 27.72% on two of the RF traces, exceeding the stated range. The '8%' figure appears to be the Sobel result from Table 4, not an aggregate across benchmarks. The abstract and the benefits statement should be reconciled with the full data: a median and range over all benchmarks and traces would be a fairer summary, and the text should say that errors can reach the upper 20s on some traces and benchmarks.
  3. [Section 4.3, Table 4] The comparison with ACCEPT uses previously published numbers from ACCEPT's technical report instead of re-running ACCEPT under the same conditions (same input traces, capacitor sizes, error metrics, and simulator setup). The paper explains that ACCEPT was evaluated only on Sobel and Activity Recognition, which justifies limiting the comparison to those two applications, but it does not establish that the reported ACCEPT numbers were obtained under conditions comparable to CheckMate's. Please state the conditions under which the ACCEPT results were generated, or, if those conditions are not known to be matched, soften the 'outperforming ACCEPT' claim to a stated comparison of the reported numbers rather than a controlled benchmark.
minor comments (7)
  1. [Eq. (2)] The definition em = |ao - aa| / ao is ambiguous for output types where higher values are better (e.g., F1-score, SSIM) and for cases where ao can be zero. Please clarify how each accuracy class in Table 1 is normalized to produce a comparable em in [0,1] or state the cap at 100% error as done elsewhere.
  2. [Section 4.2, Bitcount] The text says 'an output error of less than 6%' for Bitcount, but Table 3 shows 27.72% for RF#1 and RF#4. Please correct the text or the table so the numbers are consistent.
  3. [Figure 8] The figure combines output error percentage and power-cycle reduction percentage in one bar chart with a single axis; a dual-axis plot or separate panels would avoid visual ambiguity about which scale applies to which bar.
  4. [Section 4.2 vs Table 5] The headline 'up to 60%' reduction in Section 1 refers to simulation results, but the testbed shows 66.6% for Sobel (Table 5). Please clarify which measurement basis the headline claim refers to, since the discrepancy is modest but could confuse readers.
  5. [Section 5] The Discussion and Limitations section discusses approximation overhead and privacy, but it does not acknowledge that the accuracy results are in-sample with respect to the optimization traces. Adding a sentence on held-out validation as an open limitation would strengthen the paper's rigor.
  6. [Section 4.5] The user study reports a reduction in average time from 13.93 to 2.56 minutes and error rates from 51–82% down to CheckMate's values, but no statistical significance tests are provided for n=17. The word 'significant' should be qualified or replaced with a descriptive comparison.
  7. [References] Several references are incomplete: [24] (Egypt) has no publication venue or year, [50] omits author names, and [51] lacks a full bibliographic entry. Please complete them.

Circularity Check

2 steps flagged · score 5.0 of 10

Reported error and cycle figures are the optimized objective evaluated on the same input traces used for fitting; no held-out input evaluation supports the accuracy claims.

  1. fitted input called prediction [Section 2.2, Section 3.3 (Eqs. 1-3), Section 4.2, Abstract]
    "The application is executed inside this simulated environment using user-provided input traces. The simulator evaluates output error rates and power cycle reductions, producing quantitative metrics that the LLM itself cannot compute."

    Section 3.3 defines those simulator-produced metrics as em and cr (Eqs. 2-3) and makes em+cr the optimization metric (Eq. 1) that Bayesian optimization minimizes. Section 4.2 and the Abstract then report the error rates and cycle reductions at the optimizer-selected knob values, measured on the same user-provided input traces that drove the optimization. Thus the headline 'accuracy loss of just 8%' is the em component of the optimized objective on the fitting traces, not an independent evaluation on held-out inputs; no held-out input traces or distribution-shift analysis are presented.

  2. fitted input called prediction [Section 4.2, Boyer-Moore String Search]
    "During the function selection phase, the LLM identified an opportunity to approximate the initialization step in the Boyer-Moore algorithm. Specifically, it observed that the input traces did not cover the full ASCII range, reducing the bad character table to include only frequently encountered characters. ... Without the input trace, the LLM skipped the bad character table approximation and relied solely on perforating the main search loop, resulting in a consistent 6.6% error and a 10% reduction in power cycles."

    This ablation directly demonstrates that the reported 31% cycle savings (Figure 8d) are obtained by conditioning the approximation on the evaluation input trace: the LLM inspects the user-provided trace, tailors the bad-character table to that trace, and the reported error and cycle counts are then measured on that same trace. The same input is therefore both the fitting signal and the evaluation data, making the trace-specific speedup a fitted result rather than evidence about unseen deployment inputs.

full rationale

The core mechanism is not intrinsically circular: LLM-generated approximations are validated, knobs are tuned by Bayesian optimization against a stated objective, and the hardware testbed (Section 4.4, Table 5) independently corroborates the power-cycle half of the claims. However, the accuracy half of the central claim is in-sample by construction. Section 3.3 states that both em and cr are evaluated in the Fused simulator, and the optimization metric in Eq. 1 is em+cr; the error percentages reported in Section 4.2 and the Abstract are exactly the em values at the optimizer-selected knobs on the same user-provided input traces used for optimization. The Boyer-Moore ablation makes the trace-conditioning explicit: with the input trace withheld, the same application yields only 10% cycle reduction instead of 31%. No held-out input traces or distribution-shift analysis is provided, so the accuracy results are a report of the fitted objective rather than a prediction of generalization. Independent grounding from the testbed and the external ACCEPT comparison keeps the overall circularity moderate rather than total. Separately, Table 3 reports Bitcount errors of 27.72% on RF#1 and RF#4, which contradicts the 6-25% error range claimed in Section 1, an internal consistency issue rather than a circularity issue.

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

The paper introduces no fundamental free parameters or invented entities; its knobs are application-specific variables tuned by Bayesian optimization, which are not claimed as universal constants. The main implicit assumptions are about simulator fidelity, trace representativeness, and generalization across checkpointing schemes.

free parameters (3)
  • Knob variables (e.g., loop perforation factor, precision scale) for each benchmark
    These are introduced by LLM-generated code and tuned by Bayesian optimization on user-provided traces; the reported power-cycle and error numbers depend on the specific optimized values, which are not tabulated per final configuration.
  • Error bound eb (set to 30%) = 30% (upper bound)
    A user-specified constraint that defines the search space in Bayesian optimization; the paper uses 30% based on prior work, but it is a chosen threshold, not a derived quantity.
  • Bayesian optimization iteration count (150) = 150
    Selected by hand to trade off convergence and runtime; the paper notes further iterations give marginal gains but provides no sensitivity analysis across applications.
assumptions (4)
  • domain assumption The Fused simulator accurately models energy consumption, checkpointing, and reboots for MSP430 and Cortex-M targets.
    Section 4 uses Fused with ManagedState for all evaluations and claims hardware validation on one MSP430 board with RF traces; simulation fidelity across other platforms is assumed.
  • ad hoc to paper The user-provided input traces used for error measurement are representative of deployment inputs, so the optimized error bounds hold beyond the tuning set.
    Sections 3.3 and 4.2 evaluate em and cr on the same traces used by the Bayesian optimizer; no holdout traces are used, so generalization is assumed without evidence.
  • domain assumption Bayesian optimization over 150 iterations reaches configurations near the global minimum for all six applications.
    Section 4 states 150 iterations balances overhead and near-optimality, with convergence plots but no guarantee or cross-check.
  • domain assumption Checkpointing overhead and behavior of ManagedState are representative of other checkpointing schemes, so the reported power-cycle reductions generalize.
    Section 4 states benefits are expected to generalize across checkpointing solutions without testing alternatives.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CheckMate: LLM-Powered Approximate Intermittent Computing." pith.science (2026). https://pith.science/paper/RZ3NQUGQ

@misc{pith2026241117732,
  author       = {Pith},
  title        = {Pith review of: CheckMate: LLM-Powered Approximate Intermittent Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RZ3NQUGQ}},
  note         = {Machine review of arXiv:2411.17732}
}
read the original abstract

Batteryless IoT systems face energy constraints exacerbated by checkpointing overhead. Approximate computing offers solutions but demands manual expertise, limiting scalability. This paper presents CheckMate, an automated framework leveraging LLMs for context-aware code approximations. CheckMate integrates validation of LLM-generated approximations to ensure correct execution and employs Bayesian optimization to fine-tune approximation parameters autonomously, eliminating the need for developer input. Tested across six IoT applications, it reduces power cycles by up to 60% with an accuracy loss of just 8%, outperforming semi-automated tools like ACCEPT in speedup and accuracy. CheckMate's results establish it as a robust, user-friendly tool and a foundational step toward automated approximation frameworks for intermittent computing.

Figures

Figures reproduced from arXiv: 2411.17732 by the authors.

Figure 1
Figure 1. CheckMate workflow. applying effective approximations. This context loss frequently led to hallucinations, where the LLM generated irrelevant or incorrect outputs. Approach: To address these issues, multiple strategies are available, including chain-of-thought (CoT) prompting with few-shot learning, fine-tuning models with additional data, or implementing retrieval￾augmented generation (RAG) to contextualize LLM out… view at source ↗
Figure 2
Figure 2. CheckMate architecture. describing their purpose, inputs, and outputs [A.1.7]. Subsequently, each function is analyzed individually [A.1.8]. The LLM evaluates the role of each function within the application, determining which are suitable for approximation and identifying the potential benefits of such approximations. Finally, using a dedicated prompt, the LLM classifies each function as either “approximate” or “do… view at source ↗
Figure 3
Figure 3. Minimizing Optimization Metric: The purple dot indi￾cates the point where the optimization metric achieves its minimum value, representing the balance between reduced power cycles and acceptable output error. Listing 4: Approximate code with knob variables. { apx_code: "/*approximated code*/", knob_variables: ["knob1"], knob_ranges: [{"knob1": [20, 100]}], knob_increments: [{"knob1": "Integer"}] } Listing 5: LLM’s o… view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: Optimization metrics for each LLM.Depicting performance of GPT-4o (right bar), GPT-4o Mini (middle bar), and Claude 3.5 Sonnet (left bar) across six applications. The lower values of the optimization metric (𝑒𝑚+𝑐𝑟) indicate better performance [PITH_FULL_IMAGE:figures/…
Figure 6
Figure 6. Figure 6: Bayesian optimization results for six applications. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Original vs approximated Sobel. (a) The original image. (b) Edge detection using the original code. (c) Edge detection using the approximated code. knob that controlled the bad character table’s size did not increase error but impacted power cycles due to the larger ta…
Figure 8
Figure 8. Figure 8: Performance results (RF#2 trace across three capacitor sizes). [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Testbed setup. stores energy from the generator’s voltage signal, powering the MCU. The diode prevents reverse discharge, blocking current flow when the generator outputs a voltage lower than the capacitor’s stored charge. Voltage levels from both the energy trace and …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

76 extracted references · 63 canonical work pages

  1. [1]

    Mikhail Afanasov, Naveed Anwar Bhatti, Dennis Campagna, Giacomo Caslini, Fabio Massimo Centonze, Koustabh Dolui, Andrea Maioli, Erica Barone, Muham- mad Hamad Alizai, Junaid Haroon Siddiqui, et al . 2020. Battery-less zero- maintenance embedded sensing at the mithræum of circus maximus. In Pro- ceedings of the 18th Conference on Embedded Networked Sensor ...

    work page 2020

  2. [2]

    Saad Ahmed, Naveed Anwar Bhatti, Muhammad Hamad Alizai, Junaid Haroon Siddiqui, and Luca Mottola. 2019. Efficient intermittent computing with differen- tial checkpointing. In Proceedings of the 20th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems . 70–81

    work page 2019

  3. [3]

    Saad Ahmed, Naveed Anwar Bhatti, Martina Brachmann, et al. 2021. A survey on program-state retention for transiently-powered systems. Journal of Systems Architecture 115 (2021), 102013

    work page 2021

  4. [4]

    Saad Ahmed, Bashima Islam, Kasim Sinan Yildirim, Marco Zimmerling, Prze- mysław Pawełczak, Muhammad Hamad Alizai, Brandon Lucia, Luca Mottola, Jacob Sorber, and Josiah Hester. 2024. The Internet of Batteryless Things. Com- mun. ACM 67, 3 (2024), 64–73

    work page 2024

  5. [5]

    Jawaher Alharbi and Arshad Jhumka. 2023. Checkpointing in Transiently Pow- ered IoT Networks. In Proceedings of the 22nd International Conference on Infor- mation Processing in Sensor Networks . 316–317

    work page 2023

  6. [6]

    Jawaher Alharbi, Arshad Jhumka, and Daniele Palossi. 2023. To Checkpoint or Not to Checkpoint: That is the Question (EWSN). ACM, New York, NY, USA, 124–131

    work page 2023

  7. [7]

    Anthropic. [n. d.]. Claude 3.5: Introducing a New Era of AI Assistance. https: //www.anthropic.com/news/claude-3-5-sonnet. Accessed: 2024-11-07

    work page 2024

  8. [8]

    Mattia Antonini, Massimo Vecchio, Fabio Antonelli, Pietro Ducange, and Charith Perera. 2018. Smart audio sensors in the internet of things edge for anomaly detection. IEEE Access 6 (2018), 67594–67610

    work page 2018

Show all 76 references
  1. [9]

    Brendan Ashworth. 2019. Fast Fourier Transform. https://github.com/ brendanashworth/fft-small

    2019

  2. [10]

    Fulvio Bambusi, Francesco Cerizzi, Yamin Lee, et al. 2022. The case for approxi- mate intermittent computing. In 2022 21st ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN) . IEEE, 463–476

    2022

  3. [11]

    Rei Barjami, Antonio Miele, and Luca Mottola. 2024. Intermittent Inference: Trading a 1% Accuracy Loss for a 1.9x Throughput Speedup. In Proceedings of the 22nd ACM Conference on Embedded Networked Sensor Systems (Hangzhou, China) (SenSys ’24). Association for Computing Machin...

    2024

  4. [12]

    Batronix. 2024. Rigol DG1022 Waveform Generator. https://www.batronix.com/ shop/waveform-generator/Rigol-DG1022.html. Accessed: 2024-11-12

    2024

  5. [13]

    Naveed Bhatti, Luca Mottola, et al. 2016. Efficient state retention for transiently- powered embedded sensing. In Proceedings of the 2016 International Conference on Embedded Wireless Systems and Networks . 137–148

    2016

  6. [14]

    Naveed Anwar Bhatti and Luca Mottola. 2017. HarvOS: Efficient code instru- mentation for transiently-powered embedded sensing. In Proceedings of the 16th ACM/IEEE International Conference on Information Processing in Sensor Networks . 209–219

    2017

  7. [15]

    Harrison Chase. 2024. LangChain Documentation. https://www.langchain.com/. Accessed: 2024-06-28

    2024

  8. [16]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Pondé de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott G...

    2021 arXiv

  9. [17]

    Alexei Colin and Brandon Lucia. 2016. Chain: tasks and channels for reliable intermittent programs. In Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. 514–530

    2016

  10. [18]

    Alexei Colin, Emily Ruppel, and Brandon Lucia. 2018. A reconfigurable en- ergy storage architecture for energy-harvesting devices. In Proceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems . 767–781

    2018

  11. [19]

    DeepSeek-AI. 2024. DeepSeek-V2: A Strong, Economical, and Efficient Mixture- of-Experts Language Model. arXiv:2405.04434 [cs.CL]

    2024 arXiv

  12. [20]

    Menachem Domb. 2021. A framework of signature-matching-algorithms for IoT intrusion detection. In Proceedings of the Future Technologies Conference (FTC) 2020, Volume 3. Springer, 889–898

    2021

  13. [21]

    Joakim Eriksson and et al. 2007. Poster Abstract: MSPsim–an Extensible Simulator for MSP430-equipped Sensor Boards. (01 2007)

    2007

  14. [22]

    Karthik Ganesan, Joshua San Miguel, and Natalie Enright Jerger. 2019. The what’s next intermittent computing architecture. In 2019 IEEE International Symposium on High Performance Computer Architecture (HPCA) . IEEE, 211–223

    2019

  15. [23]

    Alessandro Ghibellini, Luciano Bononi, and Marco Di Felice. 2022. Intelligence at the iot edge: Activity recognition with low-power microcontrollers and con- volutional neural networks. In 2022 IEEE 19th Annual Consumer Communications & Networking Conference (CCNC). IEEE, 707–710

    2022

  16. [24]

    Andreas Gustafsson. unknown. Egypt - Create Call Graph from GCC RTL Dump. https://www.gson.org/egypt/egypt.html. Retrieved June 23, 2024

    2024

  17. [25]

    Guthaus and et al

    M.R. Guthaus and et al. 2001. MiBench: A free, commercially representative embedded benchmark suite. InProceedings of the Fourth Annual IEEE International Workshop on Workload Characterization. WWC-4 (Cat. No.01EX538) . 3–14. https: //doi.org/10.1109/WWC.2001.990739

    2001

  18. [26]

    Tim Head, MechCoder, Gilles Louppe, et al. 2018. scikit-optimize/scikit-optimize: v0.5.2. https://doi.org/10.5281/zenodo.1207017

    2018 doi

  19. [27]

    Josiah Hester and Jacob Sorber. 2017. Flicker: Rapid prototyping for the battery- less internet-of-things. In Proceedings of the 15th ACM Conference on Embedded Network Sensor Systems. 1–13

    2017

  20. [28]

    Texas Instruments. [n. d.]. MSP430 MCUs - Ultra-low-power microcontrollers for embedded development. https://www.ti.com/design-development/embedded- development/msp430-mcus.html. Accessed: 2024-11-07

    2024

  21. [29]

    Bashima Islam and Shahriar Nirjon. 2019. Zygarde: Time-sensitive on-device deep inference and adaptation on intermittently-powered systems.arXiv preprint arXiv:1905.03854 (2019)

    2019 arXiv

  22. [30]

    Kashif Javed, Naveed Anwar Bhatti, and Mohammad Imran. 2023. MOPTIC- SM: Sleep mode-enabled multi-optimized intermittent computing for transiently powered systems. Journal of Systems Architecture 137 (2023), 102850

    2023

  23. [31]

    Hrishikesh Jayakumar, Arnab Raha, Woo Suk Lee, et al. 2015. QuickRecall: A HW/SW approach for computing across power cycles in transiently powered computers. ACM Journal on Emerging Technologies in Computing Systems (JETC) 12, 1 (2015), 1–19

    2015

  24. [32]

    Seunghyeok Jeon, Yonghun Choi, Yeonwoo Cho, et al. 2023. HarvNet: Resource- Optimized Operation of Multi-Exit Deep Neural Networks on Energy Harvesting Devices. In Proceedings of the 21st Annual International Conference on Mobile Systems, Applications and Services (Helsinki, F...

    2023

  25. [33]

    Min Jia, Edwin Hsing-Mean Sha, Qingfeng Zhuge, et al. 2022. Transient comput- ing for energy harvesting systems: A survey. Journal of Systems Architecture 132 (2022), 102743

    2022

  26. [34]

    Rajeev Joshi, Md Adnan Zaman, and Srinivas Katkoori. 2022. Fast Sobel edge detection for IoT edge devices. SN Computer Science 3, 4 (2022), 302

    2022

  27. [35]

    Nick Kanopoulos, Nagesh Vasanthavada, and Robert L Baker. 1988. Design of an image edge detection filter using the Sobel operator. IEEE Journal of solid-state circuits 23, 2 (1988), 358–367

    1988

  28. [36]

    Daya S Khudia, Babak Zamirai, Mehrzad Samadi, et al. 2015. Rumba: An online quality management system for approximate computing. In 2015 ACM/IEEE 42nd Annual International Symposium on Computer Architecture (ISCA) . 554–566. https://doi.org/10.1145/2749469.2750371

    2015

  29. [37]

    Chih-Chia Lin, Chia-Yin Liu, Chih-Hsuan Yen, et al. 2023. Intermittent-aware neural network pruning. In 2023 60th ACM/IEEE Design Automation Conference (DAC). IEEE, 1–6

    2023

  30. [38]

    Chunwei Liu. 2022. Fast and Effective Compression for IoT Systems . Ph. D. Disser- tation. The University of Chicago

    2022

  31. [39]

    Brandon Lucia, Vignesh Balaji, Alexei Colin, et al. 2017. Intermittent comput- ing: Challenges and opportunities. 2nd Summit on Advances in Programming Languages (SNAPL 2017) (2017)

    2017

  32. [40]

    Kiwan Maeng, Alexei Colin, and Brandon Lucia. 2017. Alpaca: Intermittent exe- cution without checkpoints. Proceedings of the ACM on Programming Languages 1, OOPSLA (2017), 1–30

    2017

  33. [41]

    Kiwan Maeng and Brandon Lucia. 2018. Adaptive dynamic checkpointing for safe efficient intermittent computing. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18) . 129–144

    2018

  34. [42]

    Andrea Maioli and Luca Mottola. 2021. Alfred: Virtual memory for intermittent computing. In Proceedings of the 19th ACM Conference on Embedded Networked Sensor Systems. 261–273

    2021

  35. [43]

    Microsoft. 2024. Language Server Protocol Documentation. https://microsoft. github.io/language-server-protocol/. Accessed: 2024-06-28

    2024

  36. [44]

    Nausheen Mohammed, Akash Lal, Aseem Rastogi, Subhajit Roy, and Rahul Sharma. 2024. Enabling Memory Safety of C Programs using LLMs. arXiv preprint arXiv:2404.01096 (2024)

    2024 arXiv

  37. [45]

    George Oikonomou, Simon Duquennoy, Atis Elsts, Joakim Eriksson, Yasuyuki Tanaka, and Nicolas Tsiftes. 2022. The Contiki-NG open source operating system for next generation IoT devices. SoftwareX 18 (2022), 101089. Conference’17, July 2017, Washington, DC, USA Sayyid-Ali, et al

    2022

  38. [46]

    OpenAI. 2024. OpenAI Platform Documentation: GPT-4 Turbo and GPT-4. https: //platform.openai.com/docs/models/gpt-4-turbo-and-gpt-4. Accessed: 2024-06- 28

    2024

  39. [47]

    Konstantinos Parasyris, James Diffenderfer, Harshitha Menon, Ignacio Laguna, Jackson Vanover, Ryan Vogt, and Daniel Osei-Kuffuor. 2022. Approximate Com- puting Through the Lens of Uncertainty Quantification. In SC22: International Conference for High Performance Computing, Net...

    2022 arXiv

  40. [48]

    DRAGOS, -S, TEFAN PERJU. 2019. Applying Memoization as an Approximate Computing Method for Transiently Powered Systems. (2019)

    2019

  41. [49]

    PyVISA Contributors. 2024. PyVISA Documentation. https://pyvisa.readthedocs. io/en/latest/. Accessed: 2024-11-12

    2024

  42. [50]

    Jeya Prakash R and Anju S Pillai. 2022. Enhancing Energy Efficiency of Intensive Computing Applications using Approximate Computing. In2022 3rd International Conference on Electronics and Sustainable Communication Systems (ICESC) . 1231–

    2022

  43. [51]

    Benjamin Ransford. [n. d.]. Mspsim/traces at mementos · Ransford/mspsim. https://github.com/ransford/mspsim/tree/mementos/traces

  44. [52]

    Benjamin Ransford and et al. 2011. Mementos: system support for long-running computation on RFID-scale devices. In ASPLOS (California, USA). New York, NY, USA, 159–170. https://doi.org/10.1145/1950365.1950386

    2011

  45. [53]

    Nafiul Rashid, Berken Utku Demirel, and Mohammad Abdullah Al Faruque. 2022. AHAR: Adaptive CNN for energy-efficient human activity recognition in low- power edge devices. IEEE Internet of Things Journal 9, 15 (2022), 13041–13051

    2022

  46. [54]

    Renode. [n. d.]. Renode/Renode: Renode - Antmicro’s open source simulation and Virtual Development Framework for complex embedded systems. https: //github.com/renode/renode

  47. [55]

    Emily Ruppel, Milijana Surbatovich, Harsh Desai, et al. 2022. An Architectural Charge Management Interface for Energy-Harvesting Systems. In 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). 318–335. https: //doi.org/10.1109/MICRO56248.2022.00034

    2022

  48. [56]

    Adrian Sampson, Andre Baixo, Benjamin Ransford, et al . 2015. ACCEPT: A Programmer-Guided Compiler Framework for Practical Approximate Computing. In University of Washington Technical Report. https://dada.cs.washington.edu/ research/tr/2015/01/UW-CSE-15-01-01.pdf

    2015

  49. [57]

    Nicholas D Sanders, Richard M Everson, Jonathan E Fieldsend, and Alma AM Rahat. 2019. Bayesian search for robust optima. arXiv preprint arXiv:1904.11416

    2019 arXiv

  50. [58]

    Seun Sangodoyin, Frank T Werner, Baki B Yilmaz, Chia-Lin Cheng, Elvan M Ugurlu, Nader Sehatbakhsh, Milos Prvulović, and Alenka Zajic. 2020. Side- channel propagation measurements and modeling for hardware security in iot devices. IEEE Transactions on Antennas and Propagation 6...

    2020

  51. [59]

    Sivert T Sliper, Domenico Balsamo, Nikos Nikoleris, William Wang, Alex S Weddell, and Geoff V Merrett. 2019. Efficient state retention through paged memory management for reactive transient computing. In Proceedings of the 56th Annual Design Automation Conference 2019. 1–6

    2019

  52. [60]

    Sliper, William Wang, Nikos Nikoleris, Alex S

    Sivert T. Sliper, William Wang, Nikos Nikoleris, Alex S. Weddell, and Geoff V. Mer- rett. 2020. Fused: Closed-Loop Performance and Energy Simulation of Embedded Systems. In 2020 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). 263–272. htt...

    2020

  53. [61]

    Ankur Verma, Ayush Goyal, Soundar Kumara, and Thomas Kurfess. 2021. Edge- cloud computing performance benchmarking for IoT based machinery vibration monitoring. Manufacturing Letters 27 (2021), 39–41

    2021

  54. [62]

    Winter, P

    T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander. 2012. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC 6550, https://datatracker.ietf.org/doc/html/rfc6550. Accessed: 2024-11-07

    2012

  55. [63]

    Chih-Hsuan Yen, Hashan Roshantha Mendis, Tei-Wei Kuo, et al . 2023. Keep in Balance: Runtime-reconfigurable Intermittent Deep Inference. ACM Trans. Embed. Comput. Syst. 22, 5s, Article 124 (Sept. 2023), 25 pages. https://doi.org/ 10.1145/3607918

    2023 doi

  56. [64]

    Approxi- mation Engine

    Kasım Sinan Yıldırım, Amjad Yousef Majid, Dimitris Patoukas, Koen Schaper, Przemyslaw Pawelczak, and Josiah Hester. 2018. Ink: Reactive kernel for tiny batteryless sensors. In Proceedings of the 16th ACM Conference on Embedded Networked Sensor Systems. 41–53. CheckMate: LLM-Po...

    2018

  57. [66]

    If so, you will annotate the code, adding comments where approximations can be applied, along with descriptions of what and how to apply them

    Planning/Annotation Step: After determining the function's purpose, you will assess whether it is safe to approximate. If so, you will annotate the code, adding comments where approximations can be applied, along with descriptions of what and how to apply them

  58. [67]

    These steps will be repeated for each function in our program's codebase

    Approximation Step: You will then be prompted again to apply the approximations you previously annotated. These steps will be repeated for each function in our program's codebase. If a function contains calls to other functions, the conversation history of applied approximatio...

    2017

  59. [68]

    approximated_code: The full block of code that you generated

  60. [69]

    These are the "knobs."

    knob_variables: A list of all the variable names that can be tuned or adjusted in the code. These are the "knobs."

  61. [70]

    knob_ranges: The possible ranges of each knob variable (in the form of minimum and maximum values or specific values, if applicable)

  62. [71]

    Specify whether the increment is a Real number or an Integer

    knob_increments: The increments by which each knob variable can change. Specify whether the increment is a Real number or an Integer. Format the output as a clean and structured JSON object as described here: {output_instuctions} Listing 14: Few-shot prompt to guide LLM effici...

    2017

  63. [72]

    You will be provided with a list of source files

  64. [73]

    Generate a Makefile that compiles these files into an executable named main

  65. [74]

    Include the necessary rules to compile object files from the source files

  66. [75]

    Create a clean rule to remove all object files and the executable

  67. [76]

    ```"). The command that will be run is just

    Use gcc as the compiler. Listing 17: Makefile generation Given a list of files in a directory, output a Makefile to compile the application. files = {files_list} Output only the Makefile content, no other text. Your exact output will be pasted into the Makefile ( so do not inc...

  68. [1236]

    https://doi.org/10.1109/ICESC54411.2022.9885429

    2022

Pith tools

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