`FastProcessor` now returns an error when cycle count is exceeded #2537

plafer · 2026-01-05T17:14:09Z

As part of this change, we also added a new constructor FastProcessor::new_with_options(), which allows users to pass in a ExecutionOptions.

Al-Kindi-0

LGTM

processor/src/fast/mod.rs

plafer · 2026-01-05T19:34:43Z

processor/src/fast/mod.rs

-    /// Creates a new `FastProcessor` instance, set to debug mode, with the given stack
-    /// and advice inputs.
+    /// Creates a new `FastProcessor` instance with the given stack and advice inputs, where
+    /// debugging and tracing are enabled.
    ///
    /// # Panics
    /// - Panics if the length of `stack_inputs` is greater than `MIN_STACK_DEPTH`.
    pub fn new_debug(stack_inputs: &[Felt], advice_inputs: AdviceInputs) -> Self {
-        Self::initialize(stack_inputs, advice_inputs, true)
+        Self::new_with_options(
+            stack_inputs,
+            advice_inputs,
+            ExecutionOptions::default().with_debugging(true).with_tracing(),
+        )


Note that I enabled tracing with the new_debug() to preserve former functionality (mostly in tests).

Not for this PR, but would be great to "normalize" ExecutionOptions at some point. For example, it is a bit odd that with_dubbing() takes a parameter while with_tracing() does not.

plafer · 2026-01-05T21:14:44Z

processor/src/fast/mod.rs

+    /// Returns true if decorators should be executed.
+    ///
+    /// This corresponds to either being in debug mode (for debug decorators) or having tracing
+    /// enabled (for trace decorators).
+    fn should_execute_decorators(&self) -> bool {
+        self.in_debug_mode() || self.options.enable_tracing()
+    }


@Al-Kindi-0 I re-requested a review, since I added this method since you approved (which I only noticed was needed when working on #2539). Basically, we should execute decorators not only in debug mode, but also when tracing is enabled.

This has the unfortunate consequence that the processor will be slowed down when only tracing (but not debug mode) is enabled.

This is a by-product of the fact that AsmOp decorators should not be lumped in with Debug and Trace decorators, since they do not need to be executed at runtime. Currently, if tracing mode is enabled (or even debug mode just for debug decorators), the processor needlessly loops through all AsmOp decorators, which really isn't needed - we only need to look them up when an error occurs. AsmOp decorators should be stored separately in their own CSR matrix. This is as previously discussed with @huitseeker.

Opened #2541 to track

bobbinth

Looks good! Thank you! I left just a few small comments inline.

Also, now we are doing a bit more work on every cycle - did this have any noticeable impact on performance?

bobbinth · 2026-01-05T21:04:45Z

processor/src/fast/mod.rs

+    pub fn new_with_options(
+        stack_inputs: &[Felt],
+        advice_inputs: AdviceInputs,
+        options: ExecutionOptions,
+    ) -> Self {


Not for this PR, but we could consider encapsulating stack and advice inputs into a single struct - e.g., something like ProgramInputs.

bobbinth · 2026-01-05T21:05:49Z

processor/src/fast/mod.rs

-    /// Creates a new `FastProcessor` instance, set to debug mode, with the given stack
-    /// and advice inputs.
+    /// Creates a new `FastProcessor` instance with the given stack and advice inputs, where
+    /// debugging and tracing are enabled.
    ///
    /// # Panics
    /// - Panics if the length of `stack_inputs` is greater than `MIN_STACK_DEPTH`.
    pub fn new_debug(stack_inputs: &[Felt], advice_inputs: AdviceInputs) -> Self {
-        Self::initialize(stack_inputs, advice_inputs, true)
+        Self::new_with_options(
+            stack_inputs,
+            advice_inputs,
+            ExecutionOptions::default().with_debugging(true).with_tracing(),
+        )


Not for this PR, but would be great to "normalize" ExecutionOptions at some point. For example, it is a bit odd that with_dubbing() takes a parameter while with_tracing() does not.

bobbinth · 2026-01-05T21:20:01Z

processor/src/fast/mod.rs

+    fn should_execute_decorators(&self) -> bool {
+        self.in_debug_mode() || self.options.enable_tracing()
+    }


Should we add #[inline(always)] here as well?

Also, not for this PR, but I'm wondering if we should simplify the debug mode - basically, have a single setting that enables both debugging and tracing. I'm not really sure there is a lot of benefit of having them separate.

Should we add #[inline(always)] here as well?

Done

Also, not for this PR, but I'm wondering if we should simplify the debug mode - basically, have a single setting that enables both debugging and tracing. I'm not really sure there is a lot of benefit of having them separate.

Agreed, though let's address this when we know whether better what tracing ends up looking like.

air/src/errors.rs

huitseeker · 2026-01-06T06:50:39Z

processor/src/fast/mod.rs


-        if stopper.should_stop(self) {
-            ControlFlow::Break(())
+        if self.clk >= self.options.max_cycles() as usize {


To answer @bobbinth's question about performance impact: I ran make exec-info and a blake3 proving benchmark on both this branch and next.

Results (blake3_1to1 prove):

PR branch: total 33.1s, execute_for_trace 7.45ms, build_trace 78.3ms

next branch: total 33.1s, execute_for_trace 11.1ms, build_trace 87.0ms

No regression, execution is actually slightly faster on this branch (likely noise, but definitely not slower).

air/src/errors.rs

…Two` This is not an actual requirement, and some tests make use of fragments of size that are not a power of 2.

… use it internally

We also add a new method `FastProcessor::should_execute_decorator()`, which takes into account that we should execute decorators in debug mode *and* when tracing is enabled.

…)` method. Continuations should be passed directly rather than "fixing the continuation" after the call to `increment_clk()` with `map_break()` as was done previously. This is generally cleaner, and allows the `increment_clk_*()` methods to return internal errors as well.

This is done in the new `FastProcessor::increment_clk_with_continuation()`.

plafer requested review from Al-Kindi-0, adr1anh and huitseeker January 5, 2026 17:14

Base automatically changed from huitseeker/merge-main-into-next to next January 5, 2026 17:29

plafer force-pushed the plafer-2535-cycle-count-limit branch 2 times, most recently from 710a357 to 6e19dd6 Compare January 5, 2026 17:55

plafer mentioned this pull request Jan 5, 2026

Improve FastProcessor debug mode #2479

Closed

Al-Kindi-0 approved these changes Jan 5, 2026

View reviewed changes

processor/src/fast/mod.rs Outdated Show resolved Hide resolved

plafer force-pushed the plafer-2535-cycle-count-limit branch 3 times, most recently from 3b1f781 to f3e2754 Compare January 5, 2026 19:33

plafer commented Jan 5, 2026

View reviewed changes

plafer force-pushed the plafer-2535-cycle-count-limit branch from f3e2754 to cbdabec Compare January 5, 2026 19:35

plafer mentioned this pull request Jan 5, 2026

Only execute trace decorators when tracing is enabled #2539

Merged

plafer force-pushed the plafer-2535-cycle-count-limit branch 2 times, most recently from 15bd24a to bcf0479 Compare January 5, 2026 21:07

plafer requested a review from Al-Kindi-0 January 5, 2026 21:07

plafer commented Jan 5, 2026

View reviewed changes

bobbinth approved these changes Jan 5, 2026

View reviewed changes

plafer force-pushed the plafer-2535-cycle-count-limit branch from bcf0479 to 2bf0d59 Compare January 5, 2026 21:26

plafer commented Jan 5, 2026

View reviewed changes

air/src/errors.rs Show resolved Hide resolved

plafer force-pushed the plafer-2535-cycle-count-limit branch from 2bf0d59 to 7685950 Compare January 5, 2026 21:30

Al-Kindi-0 approved these changes Jan 6, 2026

View reviewed changes

huitseeker mentioned this pull request Jan 6, 2026

feat: store AsmOp decorators in their own DebugInfo section #2541

Open

huitseeker approved these changes Jan 6, 2026

View reviewed changes

plafer added 5 commits January 6, 2026 09:27

chore: remove `ExecutionOptionsError::CoreTraceFragmentSizeNotPowerOf…

033e374

…Two` This is not an actual requirement, and some tests make use of fragments of size that are not a power of 2.

chore(refactor): introduce FastProcessor::in_debug_mode() method, and…

c1d4a12

… use it internally

chore: add options: ExecutionOptions field to FastProcessor

29ae23a

We also add a new method `FastProcessor::should_execute_decorator()`, which takes into account that we should execute decorators in debug mode *and* when tracing is enabled.

chore: expose new FastProcessor::new_with_options() constructor.

da8bb5a

plafer added 2 commits January 6, 2026 09:27

feat(processor): check whether the max number of cycles were exceeded

dd380b6

This is done in the new `FastProcessor::increment_clk_with_continuation()`.

chore: changelog for PR 2537

231ef56

plafer force-pushed the plafer-2535-cycle-count-limit branch from 7685950 to 231ef56 Compare January 6, 2026 14:28

plafer merged commit 75bcff1 into next Jan 6, 2026
16 checks passed

plafer deleted the plafer-2535-cycle-count-limit branch January 6, 2026 14:42

FastProcessor now returns an error when cycle count is exceeded #2537

FastProcessor now returns an error when cycle count is exceeded #2537

Uh oh!

Conversation

plafer commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Al-Kindi-0 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

`FastProcessor` now returns an error when cycle count is exceeded #2537

`FastProcessor` now returns an error when cycle count is exceeded #2537

plafer commented Jan 5, 2026 •

edited

Loading