Rulebook: bringing co-routines to reinforcement learning environments

Giovanni Agosta; Massimo Fioravanti; Samuele Pasini

REVIEW 4 major objections 5 minor 20 references

Rulebook: bringing co-routines to reinforcement learning environments

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

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

Pith's one-line read A compiled coroutine DSL lets reinforcement-learning environments be written as sequential programs while running as fast as handwritten C++.

desk verdict Working coroutine-DSL compiler for RL environments with impressive LOC cuts and credible performance, but the 'no overhead' claim overreaches the benchmark data. read the letter →

arxiv 2504.19625 v1 pith:B7MZTBWD submitted 2025-04-28 cs.PL cs.LG

Massimo Fioravanti , Samuele Pasini , Giovanni Agosta This is my paper · ORCID

classification cs.PLcs.LG

keywords domain-specificlanguageco-routinesreinforcementlearningenvironmentsstatemachinegenerationactionpreconditionsserializationcompilersboardgames

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

Rulebook is a compiled domain-specific language for writing reinforcement-learning environments as coroutines: the author writes sequential-looking code with action statements, and the compiler turns that into the explicit state machine that RL libraries require. The paper claims this delivers the ergonomics of coroutine style—no manual state variables, inspectable and serializable frames—without the performance penalty that usually accompanies such abstraction. In measurements against handwritten C++ implementations of six board games, Rulebook-compiled code runs at relative speeds from 0.81x to 3.49x, which the paper reads as parity or better. If the claim holds, environment builders can write larger, more sophisticated simulators in less code and automatically obtain fuzzers, Python wrappers, printers, parsers, and serializers from the same source file.

What carries the argument

The load-bearing construct is the action statement, a yield-like suspension point written inside an action declaration as `act mark(Int x, Int y) { preconditions }`: it simultaneously declares the arguments a caller may pass on resume and the conditions that must be true for the resume to be legal. The compiler turns each action statement into two generated member functions, one that checks the preconditions and one that resumes the coroutine, and the collection of these functions plus the resume index is the generated state machine. Frame variables declared with `frm` become fields of that state object, giving inspectability and serializability. A zero-overhead traits system lets user-defined types override serialization without virtual calls, and the compiler's type checking grounds the static-analysis claim: the control-flow graph of a Rulebook action is an Action Flow Graph that approximates the valid action sequences as a finite-state machine, whereas a conventional `step`-function environment exposes only the fully connected graph.

What would settle it

Run a standard RL training loop against a Rulebook-generated environment and against the equivalent handwritten C++ implementation with the same agent, comparing total wall-clock time including observation serialization; if the Rulebook loop is slower, the paper's 'no performance overhead' claim is falsified.

Watch

Extended reading notes

Core claim

The central claim is that coroutine suspension points can be made first-class, inspectable, and serializable objects without giving up compiled-language performance. In Rulebook, an action declaration such as `act play() -> TicTacToe` contains action statements that declare both the arguments a caller may resume with and the preconditions that must hold; frame variables marked `frm` live in the coroutine frame and become fields of a generated class. The Rulebook compiler replaces the coroutine with that class—a resume index plus generated precondition-checking and resuming methods—so the program executes as a plain state machine. Because serialization uses a zero-overhead traits mechanism and the coroutine frame is laid out with a C-compatible ABI, the generated code needs no heap allocation or virtual dispatch unless the user requests it. Benchmarks against handwritten C++ implementations of six board games report relative speeds from 0.81x to 3.49x, and the paper interprets the range as showing comparable or better performance.

Load-bearing premise

The 'no performance overhead' claim rests on the benchmark's assumption that measuring creation of the initial state plus a randomly generated run of valid actions captures how RL training actually uses an environment, since the same benchmark deliberately excludes action-selection time and the observation-serialization step.

Editorial extensions

If this is right

Environment code can be written in rule order without manually maintaining a resume-point variable, so the source resembles the game's rules rather than a dispatch table.
From one source file the compiler emits Python wrappers, C-compatible headers, fuzzers, and human-readable and binary printers and parsers, removing tooling code that is normally handwritten.
Every action can be checked for validity before being executed, which supports valid-action masking and fuzzing without stepping the environment.
The measured performance places Rulebook-generated code in the same range as handwritten C++ implementations across the six tested games, including the most complex one in the suite.

Reading between the lines

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

The Action Flow Graph argument suggests a static-analysis payoff the paper does not develop: the compiler could use coroutine structure to identify unreachable action sequences and prune them, something a `step`-function environment cannot expose.
The benchmark deliberately excludes action-selection time and observation serialization, so a fair test of the 'no overhead' claim would measure a full training loop, including the serialization step Rulebook is designed to provide.
Lifting the no-mutually-recursive-actions restriction would let environments call and resume one another, enabling compositional hierarchical simulations; the paper names this as future work rather than a current capability.
If the no-heap-allocation property holds generally, Rulebook environments could target embedded or hard real-time settings where dynamic allocation is prohibited; this is a speculative extension.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Rulebook is a real, working contribution: a DSL for RL environments that lets you write sequential coroutines and compiles them via MLIR into inspectable, serializable, checkable state machines, with C/Python interop and generated utilities. The LOC table is the most immediately convincing thing here—Hanabi goes from 1555 lines of OpenSpiel C++ to 185 lines of Rulebook while staying in the same performance ballpark, and Battleship gets a 188x speedup largely because OpenSpiel's version pays for undo support you don't need.

The empirical case is not as clean as the abstract suggests. Table 2 reports single runs with no error bars or statistical tests, and the headline 'no performance overhead' doesn't survive contact with the 0.81x TicTacToe result. The authors explain that the gap comes from an artificial action-log replication added for fairness, and removing it brings Rulebook ahead, but the row they report is the unfair-to-themselves one. More importantly, the benchmark measures only state creation and random transition probes. The serialization and observation-generation path—one of the paper's key selling points—is never timed. So the honest claim would be 'comparable to C++ on raw transition execution,' not 'no performance overhead' across the RL step/reset cycle. That's a wording issue as much as a methodological one, but it matters because the abstract promises it.

There's also no obvious artifact link in the text—just commit hashes and a 4Hammer repo—which is a miss for a compiler paper. The AFG argument in Section 3.2 is informal, labeled intuitive, and doesn't need to be load-bearing; it motivates the design without pretending to be a theorem. The explicit limitation on mutually recursive actions is a good sign the authors know their type system.

Who is this for? People building RL environments, especially complex simulated worlds where serialization, inspection, and fuzzing matter. They'll get real value from the generated tooling and the LOC savings. I'd want the artifact linked and the benchmark methodology tightened before relying on the performance numbers, but the core idea and implementation deserve serious referee time.

Referee Report

4 major / 5 minor

Summary. This paper presents Rulebook, a domain-specific compiled language and an MLIR-based compiler (RLC) that lets environment developers write sequential, coroutine-style action declarations with preconditions and automatically lowers them into C-ABI-compatible state-machine classes. The authors claim that these classes are inspectable, checkable, serializable/deserializable, and free of heap allocation in the coroutine lifetime, and that RLC can additionally generate Python/gymnasium wrappers, fuzzers, and printing/parsing tools for the environment. The evaluation reimplements six board games from OpenSpiel in Rulebook and compares lines of code and wall-clock time for random playouts. Reported LOC ratios range from 0.11x to 0.8x (Rulebook/OpenSpiel), and reported relative speeds range from 0.81x to 188x, with 'no performance overhead' asserted in the abstract. A large Warhammer 40k implementation is also described.

Significance. If the performance and tool-generation claims were fully substantiated, Rulebook would be a useful contribution to RL environment engineering: it would give developers coroutine-level ergonomics without manual state-machine management, and it would automatically supply serialization and checkability utilities that are usually handwritten. The strongest parts of the paper are the existence of a real compiler (RLC) built with MLIR, the six concrete OpenSpiel ports that allow an external, independent comparison, the direct LOC comparison, and the production-scale Warhammer case study. The core language design idea, compiling action preconditions into can_* check functions and resume_* functions, is concrete and plausibly valuable. However, the experimental evidence is currently too weak to support the headline no-overhead claim: the benchmarks omit the serialization/observation path, use single timing values, and contain an internal inconsistency between the abstract and Table 2.

major comments (4)

[Abstract; Section 1; Section 4, Table 2] The claim of 'no performance overhead' is not supported by the data and is stated too strongly. Table 2 reports a 0.81x relative speed for TicTacToe with action log, i.e., Rulebook is about 24% slower than OpenSpiel in that configuration, and the abstract's range 0.81x to 3.49x is inconsistent with the Battleship row, which reports 188x. The authors' explanation for the TicTacToe result, involving an artificial action-log replication and move-index decoding, is plausible, but the literal claim in the abstract and introduction should be replaced by a qualified claim such as 'comparable performance' or 'no overhead beyond the selected benchmark workload.'
[Section 4, 'Experimental results'] The benchmark workload does not include the operations that Rulebook claims to provide. It measures only initial-state creation and the application of a random sequence of valid actions until game end; it excludes action-selection time and, importantly, never measures observation serialization/deserialization or the generated Python/gymnasium step/reset interface. Since serializability is one of the five design goals in Section 3.1 and is a major motivation for the language, the current experiment cannot support end-to-end performance claims for the RL loop. Please add a benchmark that times observation-tensor serialization and the wrapper call path, and report those numbers separately from raw transition execution.
[Section 4, experimental setup] Table 2 gives one time per configuration with no error bars, no number of repetitions, and no statistical comparison, although google-benchmark is said to be used. The large speedups, e.g., 3.49x for Checkers and 188x for Battleship, are attributed to OpenSpiel's Undo and configurability features rather than to the compilation strategy; without variance estimates and a per-game discussion of confounds, a reader cannot distinguish intrinsic Rulebook performance from implementation-specific effects. Please report distributions or confidence intervals and, for each game, state exactly which implementation features are included in the comparison.
[Section 3.2, 'Static analysis advantage'] The 'intuitive proof' that coroutine-based implementations expose more static information is too informal to support the claims made. The Action Flow Graph is defined only at the level of actions, but Rulebook actions carry parameters and preconditions, so the claimed equivalence with the regular language of valid traces is not established; phrases such as 'similar to' and 'never worse' are not precise. This material should either be turned into a precise statement with definitions and a proof, or explicitly framed as a motivating design argument rather than a proven advantage.

minor comments (5)

[Listing 2] The bounds check for the y coordinate appears to contain a typo: the text reads 'y >= 3 and y <= 3', which should presumably be 'y >= 0 and y <= 3'.
[Table 2] The table is missing a Speedup row for the 'Our (w/out action log)' configuration; adding one, or explaining why it is omitted, would make the fairness discussion easier to follow.
[Section 3] The statement that 'no heap allocation is triggered in the lifetime of a Rulebook co-routine, unless requested by the user' is made without describing the compiler mechanism or providing a runtime check. Please clarify whether this is a design invariant and how it is enforced.
[Throughout] There are several typographical and grammatical errors, for example 'less when compiling their implementations less opportunities' in Section 4 and 'performs faster than' in the Analysis subsection.
[Title page] The line 'Preprint. Under review.' appears on the title page; this will need to be removed or updated for journal submission.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the performance comparison is against an external codebase, the compiler output is independently executable, and no fitted inputs or load-bearing self-citations are present.

full rationale

The paper's central claim is that Rulebook's compiler, RLC, turns coroutine-style action declarations into inspectable, serializable state machines with runtime performance comparable to handwritten C++ implementations. This claim is supported by a benchmark against OpenSpiel, an external, independently maintained codebase, with fixed commits for both RLC and OpenSpiel. No parameter is fitted to the benchmark data and then renamed as a prediction; the reported relative speeds are direct measurements. The paper also does not rely on a chain of self-citations: its references are to standard tools, textbooks, and external libraries such as MLIR, gymnasium, and OpenSpiel. The only argument that approaches a tautology is the 'static analysis advantage' discussion in Section 3.2, where an Action Flow Graph is defined as a graph whose nodes are actions, and then 'the control flow graph of play() is always an AFG' follows almost by construction. However, that passage is presented as an 'intuitive proof' and a qualitative design rationale, not as an empirical prediction or a fitted result; it does not function as load-bearing evidence for the main performance or functionality claims. The benchmark's exclusion of observation serialization and action-selection time undermines the strength of the 'no performance overhead' wording, but that is a measurement-validity concern, not a circularity: the measured quantities are not the same as the input assumptions, and the comparison remains external and falsifiable. Accordingly, no circular step meeting the evidence threshold is present.

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

The paper is a systems and tooling contribution. It introduces no fitted mathematical parameters; the only free parameters are the benchmark workloads, which are chosen by the authors. The axioms listed capture the unproven assumptions about compiler correctness, AFG approximation, and benchmark representativeness that the central claims rely on. The Rulebook language itself is the main artifact, not a postulated entity, and it has a falsifiable handle in the form of the compiler and benchmarks.

assumptions (4)

domain assumption The control-flow graph of a coroutine implementation is a better approximation of the Action Flow Graph of valid action sequences than a gym-style implementation's CFG.
Section 3.2 supports this with an example and an 'intuitive proof', but no formal theorem is given. The claim that a coroutine CFG 'is never worse' than the alternative is stated as general, yet it rests on how actions are structured in the source language.
domain assumption RLC's lowering from Rulebook coroutines to the generated state-machine class preserves the semantics of the source program.
The compiler is not formally verified and no correctness proof is provided. The paper assumes that the typechecker and passes produce a state machine equivalent to the original action declaration, which is standard compiler-construction practice.
domain assumption The benchmark methodology with random valid action sequences is representative of RL environment workloads.
Section 4 explicitly measures only game-state creation and application of a random valid-action sequence, and does not measure observation serialization or reset/step interface overhead. This assumption is load-bearing for the 'no performance overhead' claim.
domain assumption The generated state machine performs no heap allocation during the coroutine lifetime unless requested by the user.
Stated as a design property in Section 3, but not verified by experiments or formal reasoning in the paper.

invented entities (2)

Action Flow Graph (AFG)
purpose: A graph abstraction used to argue that coroutine-based environments expose more static information to the compiler than gym-style implementations.
Introduced in Section 3.2. The paper gives an example and an intuitive argument, but does not prove that the compiler's static analysis actually recovers the AFG, nor that AFG approximation yields concrete compiler optimizations. It remains a conceptual device rather than an empirically validated artifact.
Rulebook language and RLC compiler independent evidence
purpose: The proposed DSL and compiler that generate inspectable, serializable, checkable state machines from coroutine-like source.
The paper identifies RLC at a specific commit and provides benchmark results against OpenSpiel, so the system is externally testable in principle, even though the repository is not linked in the paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Rulebook: bringing co-routines to reinforcement learning environments." pith.science (2026). https://pith.science/paper/B7MZTBWD

@misc{pith2026250419625,
  author       = {Pith},
  title        = {Pith review of: Rulebook: bringing co-routines to reinforcement learning environments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/B7MZTBWD}},
  note         = {Machine review of arXiv:2504.19625}
}

read the original abstract

Reinforcement learning (RL) algorithms, due to their reliance on external systems to learn from, require digital environments (e.g., simulators) with very simple interfaces, which in turn constrain significantly the implementation of such environments. In particular, these environments are implemented either as separate processes or as state machines, leading to synchronization and communication overheads in the first case, and to unstructured programming in the second. We propose a new domain-specific, co-routine-based, compiled language, called Rulebook, designed to automatically generate the state machine required to interact with machine learning (ML) algorithms and similar applications, with no performance overhead. Rulebook allows users to express programs without needing to be aware of the specific interface required by the ML components. By decoupling the execution model of the program from the syntactical encoding of the program, and thus without the need for manual state management, Rulebook allows to create larger and more sophisticated environments at a lower development cost.

Figures

Figures reproduced from arXiv: 2504.19625 by the authors.

**Figure 1.** RLC toolchain and generated tools always return a std::coroutine_handle object, which is not specific to the particular co-routine and does not allow to inspect the co-routine object, only to cancel it or resume it. Rulebook instead fully specifies how the co-routine state is laid out in memory, therefore allowing to produce a class declaration that describes the co-routine state object. F.i., the top level declarat… view at source ↗

**Figure 2.** Action graphs In co-routine based implementations, instead, the control flow graph of play() is always an AFG, which is usually not fully connected, and thus a better approximation of the optimal AFG. Indeed, listing 10 shows a possible implementation in Rulebook that matches the example AFG. Notice that its AFG, when nodes that do not contain actions are collapsed, is identical to the AFG shown in 7 [PITH_FULL_IMA… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 15 canonical work pages

[1]

Retargetable compiler case studies

Rainer Leupers, Peter Marwedel, Rainer Leupers, and Pet er Marwedel. Retargetable compiler case studies. Retargetable Compiler T echnology for Embedded Systems: T o ols and Applica- tions, pages 67–147, 2001

work page 2001
[2]

Mlir: A compiler infrastructure for the end of moore’s law

Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Coh en, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas V asilache, and Oleksandr Zinenko. Mlir: A compiler infrastructure for the end of moore’s law. arXiv preprint arXiv:2002.11054 , 2020

arXiv 2002
[3]

Compiling onnx neural network models using mlir

Tian Jin, Gheorghe-Teodor Bercea, Tung D Le, Tong Chen, G ong Su, Haruki Imai, Y asushi Negishi, Anh Leu, Kevin O’Brien, Kiyokuni Kawachiya, et al. Compiling onnx neural network models using mlir. arXiv preprint arXiv:2008.08272 , 2020

arXiv 2008
[4]

Aiwarek: Compiling pytorch model for ai processor usi ng mlir framework

Hyunjeong Kwon, Hyun Mi Kim, Chun-Gi Lyuh, Jin-Kyu Kim, J inho Han, and Y oungsu Kwon. Aiwarek: Compiling pytorch model for ai processor usi ng mlir framework. In 2022 IEEE 4th International Conference on Artiﬁcial Intelligen ce Circuits and Systems (AICAS) , pages 463–465. IEEE, 2022

work page 2022
[5]

Mlir: Scaling compiler infrastructure for domain speciﬁc computation

Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Coh en, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas V asilache, and Ol eksandr Zinenko. Mlir: Scaling compiler infrastructure for domain speciﬁc computation. I n 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO) , pages 2–14. IEEE, 2021

work page 2021
[6]

Erika Puiutta and Eric M. S. P . V eith. Explainable reinfo rcement learning: A survey. In An- dreas Holzinger, Peter Kieseberg, A Min Tjoa, and Edgar Weip pl, editors, Machine Learning and Knowledge Extraction, pages 77–95, Cham, 2020. Springer International Publishi ng

work page 2020
[7]

A review of safe reinforcement learning: Methods, theory an d applications, 2024

Shangding Gu, Long Y ang, Y ali Du, Guang Chen, Florian Wal ter, Jun Wang, and Alois Knoll. A review of safe reinforcement learning: Methods, theory an d applications, 2024

work page 2024
[8]

Openai gym, 2016

Greg Brockman, Vicki Cheung, Ludwig Pettersson, Jonas S chneider, John Schulman, Jie Tang, and Wojciech Zaremba. Openai gym, 2016

work page 2016

Show all 20 references

[9]

Ariel Kwiatkowski, Mark Towers, Jordan Terry, John U. Ba lis, Gianluca De Cola, Tris- tan Deleu, Manuel Goulão, Andreas Kallinteris, Markus Krim mel, Arjun KG, Rodrigo Perez-Vicente, Andrea Pierré, Sander Schulhoff, Jun Jet Ta i, Hannah Tan, and Omar G. Y ounis. Gymnasium: A s...

2024 arXiv
[10]

Pgx: Hardware-accelerated parallel game si mulators for reinforcement learning

Sotetsu Koyamada, Shinri Okano, Soichiro Nishimori, Y u Murata, Keigo Habara, Haruka Kita, and Shin Ishii. Pgx: Hardware-accelerated parallel game si mulators for reinforcement learning. In Advances in Neural Information Processing Systems, volume 36, pages 45716–45743, 2023

2023
[11]

OpenSpiel: A framework for reinforcement learning in games

Marc Lanctot, Edward Lockhart, Jean-Baptiste Lespiau , Vinicius Zambaldi, Satyaki Upadhyay, Julien Pérolat, Sriram Srinivasan, Finbarr Timbers, Karl T uyls, Shayegan Omidshaﬁei, Daniel Hennes, Dustin Morrill, Paul Muller, Timo Ewalds, Ryan Faul kner, János Kramár, Bart De Vyld...

1908 arXiv
[12]

Lillicrap, and David Silver

Julian Schrittwieser, Ioannis Antonoglou, Thomas Hub ert, Karen Simonyan, Laurent Sifre, Simon Schmitt, Arthur Guez, Edward Lockhart, Demis Hassabi s, Thore Graepel, Timothy P . Lillicrap, and David Silver. Mastering atari, go, chess and shogi by planning with a learned model....

1911 arXiv
[13]

Muzero general: Open rei mplementation of muzero

Aurèle Hainaut Werner Duvaud. Muzero general: Open rei mplementation of muzero. https://github.com/werner-duvaud/muzero-general, 2019. 11

2019
[14]

Mastering atari games with limited data

Weirui Y e, Shaohuai Liu, Thanard Kurutach, Pieter Abbe el, and Y ang Gao. Mastering atari games with limited data. In NeurIPS, 2021

2021
[15]

Dijkstra

Edsger W . Dijkstra. Letters to the editor: go to stateme nt considered harmful. Commun. ACM, 11(3):147–148, March 1968

1968
[16]

The Art of Computer Programming, 3rd edition

Donald Knuth. The Art of Computer Programming, 3rd edition . Addison-Wesley, 1997

1997
[17]

Hopcroft, Rajeev Motwani, and Jeffrey D

John E. Hopcroft, Rajeev Motwani, and Jeffrey D. Ullman . Introduction to Automata Theory, Languages, and Computation (3rd Edition) . Addison-Wesley Longman Publishing Co., Inc., USA, 2006

2006
[18]

Hanabi learning environment

google deepmind. Hanabi learning environment. [online], 2019

2019
[19]

google-benchmark

google. google-benchmark. https://github.com/google/benchmark
[20]

Warhammer 40.000, 10th edition

BoardGameGeek. Warhammer 40.000, 10th edition. https://boardgamegeek.com/boardgame/386136/warhammer-40000-tenth-edition. 12

Pith tools

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

[1] [1]

Retargetable compiler case studies

Rainer Leupers, Peter Marwedel, Rainer Leupers, and Pet er Marwedel. Retargetable compiler case studies. Retargetable Compiler T echnology for Embedded Systems: T o ols and Applica- tions, pages 67–147, 2001

work page 2001

[2] [2]

Mlir: A compiler infrastructure for the end of moore’s law

Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Coh en, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas V asilache, and Oleksandr Zinenko. Mlir: A compiler infrastructure for the end of moore’s law. arXiv preprint arXiv:2002.11054 , 2020

arXiv 2002

[3] [3]

Compiling onnx neural network models using mlir

Tian Jin, Gheorghe-Teodor Bercea, Tung D Le, Tong Chen, G ong Su, Haruki Imai, Y asushi Negishi, Anh Leu, Kevin O’Brien, Kiyokuni Kawachiya, et al. Compiling onnx neural network models using mlir. arXiv preprint arXiv:2008.08272 , 2020

arXiv 2008

[4] [4]

Aiwarek: Compiling pytorch model for ai processor usi ng mlir framework

Hyunjeong Kwon, Hyun Mi Kim, Chun-Gi Lyuh, Jin-Kyu Kim, J inho Han, and Y oungsu Kwon. Aiwarek: Compiling pytorch model for ai processor usi ng mlir framework. In 2022 IEEE 4th International Conference on Artiﬁcial Intelligen ce Circuits and Systems (AICAS) , pages 463–465. IEEE, 2022

work page 2022

[5] [5]

Mlir: Scaling compiler infrastructure for domain speciﬁc computation

Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Coh en, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas V asilache, and Ol eksandr Zinenko. Mlir: Scaling compiler infrastructure for domain speciﬁc computation. I n 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO) , pages 2–14. IEEE, 2021

work page 2021

[6] [6]

Erika Puiutta and Eric M. S. P . V eith. Explainable reinfo rcement learning: A survey. In An- dreas Holzinger, Peter Kieseberg, A Min Tjoa, and Edgar Weip pl, editors, Machine Learning and Knowledge Extraction, pages 77–95, Cham, 2020. Springer International Publishi ng

work page 2020

[7] [7]

A review of safe reinforcement learning: Methods, theory an d applications, 2024

Shangding Gu, Long Y ang, Y ali Du, Guang Chen, Florian Wal ter, Jun Wang, and Alois Knoll. A review of safe reinforcement learning: Methods, theory an d applications, 2024

work page 2024

[8] [8]

Openai gym, 2016

Greg Brockman, Vicki Cheung, Ludwig Pettersson, Jonas S chneider, John Schulman, Jie Tang, and Wojciech Zaremba. Openai gym, 2016

work page 2016