bench: add ExpModInteger benchmark script and plutuscall-voltv11-expmod profile#6615
Closed
Russoul wants to merge 4 commits into
Closed
bench: add ExpModInteger benchmark script and plutuscall-voltv11-expmod profile#6615Russoul wants to merge 4 commits into
Russoul wants to merge 4 commits into
Conversation
…od profile Ports a fixed-iteration expModInteger loop benchmark into plutus-scripts-bench, wires it into tx-generator's script/redeemer resolution (data/ and scripts-fallback/), and adds a calibrated plutuscall-voltv11-expmod profile (LimitTxPerBlock_4) built off it.
… check Inline the P/S wrapper types into loose Integers and flatten the redeemer from a nested (n, (a, m)) to a flat (n, a, m), removing custom IsData instances. Move interp/seed/next into mkSimpleExpModIntegerPolicyBench's where clause so the plugin can inline them, and inline the compiled-code binding into `script`, exporting only `script`. Drop the expModInteger-vs-expected-result equality check carried over from plutus-scripts-e2e's correctness tests: this is a benchmark script, not a correctness test, so it now just force-evaluates expModInteger each iteration (`let !_ = ...`) instead of threading a running result forward. Add the same "redeemer counter must be >= 1000000" sanity check the other benchmark scripts have. Re-calibrate plutusTypeExpMod's txFee against the simplified script.
The Fermat's-little-theorem/primality justification for e0 = m - 2 stopped applying once the correctness-check-against-expected-result was dropped; nothing in the code relies on m being prime anymore.
Contributor
|
The changes from this PR have been cherry-picked into #6440 and will be merged as part of that PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
expModIntegerbenchmark loop intoplutus-scripts-bench, decoding a flat(n, a, m)from the redeemer (basea=3, prime modulusm=2^61-1), witheincrementing by 1 per iteration rather than doubling, to keep per-call cost roughly constant across the run and avoid any compiler hoisting of a loop-invariant computation.expModInteger a e m(let !_ = ...) rather than checking it against a running expected result — this is a benchmark script, not a correctness test, so there's nothing to carry forward between iterations. Includes the same "redeemer counter must be >= 1000000" sanity check the other benchmark scripts have.getAllScripts/the cabalother-moduleslist, and add adata/ExpModInteger.redeemer.json+scripts-fallback/ExpModInteger.plutusfortx-generator/calibrate-scriptresolution.plutuscall-voltv11-expmodprofile (LimitTxPerBlock_4, fee fromcalibrate-script run ExpModInteger txperblock_4) and register it viawb_profiles.mk.Calibration and the profile were verified against real local cluster runs (
make plutuscall-voltv11-expmod-auto), confirming genuineExpModIntegertransaction submissions with the expected redeemer values. The script and its calibratedtxFeewere iterated on a few times (inlining helpers, flattening the redeemer, dropping the correctness check), each time re-verified withcalibrate-scriptand a real cluster run.Note: the redeemer's loop-counter placeholder must not equal
1000000—scriptDataModifyNumber's "already found a number to change" check is a before/after equality comparison, so a placeholder that already equals the reset target is a false negative and the reset falls through to the next number instead. Documented inline where this matters.