Architecture

poly-bench is built as a modular Rust workspace where each crate handles a specific responsibility. This architecture enables clean separation between parsing, validation, code generation, execution, and reporting.

The Big Idea

• DSL files (.bench) are the source of truth for benchmark definitions
• IR (Intermediate Representation) is a normalized, validated structure that all downstream tools consume
• Runtimes are isolated per-language execution environments that run generated benchmark code
• Reporters transform raw timing data into human-readable output (console, markdown, JSON, charts)

Component Map

Every benchmark flows through the same pipeline. Your .bench file is parsed into an AST, lowered to IR, used to generate language-specific code, executed in isolated runtimes, and finally reported.

Architecture Deep-Dives

How Benchmarks Flow

1. Parse & Validate

When you run poly-bench run benchmark.bench, the DSL parser tokenizes and parses your file into an AST. The validator checks for semantic errors like undefined fixtures or missing language blocks.

2. Lower to IR

The AST is lowered to an Intermediate Representation that's fully resolved and normalized. This step resolves fixture references, merges configuration with defaults, and prepares data structures for code generation.

3. Generate Code

For each target language, poly-bench generates native benchmark code. The generated code includes imports, helper functions, fixture data, and a benchmark harness with timing code.

4. Execute in Isolated Runtimes

Each language runs in its own isolated subprocess. Runtime environments live in .polybench/runtime-env/ — each language has its own dependency directory for reproducible builds.

Further Reading

• DSL Reference — Complete syntax documentation
• Standard Library — Module reference
• CLI Reference — Command-line options
• Features — Fixtures, hooks, globalSetup, charting