WIP: Add costing for lookupCoin and valueContains builtins #7344
+1,005
−204
Conversation
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
|
Unisay
force-pushed
the
yura/costing-builtin-value
branch
from
bfdb60d to
1fbd745
Compare
- Add paramLookupCoin :: f ModelThreeArguments to BuiltinCostModelBase - Add paramValueContains :: f ModelTwoArguments to BuiltinCostModelBase Part of implementing costing for lookupCoin and valueContains builtins. Currently these functions use unimplementedCostingFun which makes them prohibitively expensive. This adds the type-level infrastructure needed for proper costing.
Updates all three cost model JSON files with initial parameter values for the new built-in functions: - lookupCoin: constant CPU cost (1000ns), constant memory (1 unit) - valueContains: constant CPU cost (1000ns), constant memory (1 unit) These are placeholder values that will be refined through benchmarking. The constant cost model reflects the O(1) complexity of both operations on Cardano's Map-based Value representation.
…d valueContains Updates the builtin function definitions to use the new cost model parameters instead of unimplementedCostingFun: - lookupCoin now uses paramLookupCoin with runCostingFunThreeArguments - valueContains now uses paramValueContains with runCostingFunTwoArguments This makes both functions usable in practice by providing reasonable costing instead of prohibitively expensive fallback costs.
Unisay
force-pushed
the
yura/costing-builtin-value
branch
2 times, most recently
from
19c3d50 to
2eec71f
Compare
Implements extensive benchmarking infrastructure for the new built-in functions: - Tests various Value sizes from tiny (1 entry) to huge (30KB) - Uses pseudo-random test data generation with StdGen for reproducibility - Covers realistic Cardano constraints (28-byte policy IDs, variable token names) - Tests pathological cases (empty keys, huge keys, edge case sizes) - Memory budget-conscious generation prevents DoS during benchmarking - Generates data for both early-hit and late-hit scenarios The benchmark suite enables accurate performance measurement to determine optimal cost model coefficients for real-world usage patterns.
Extends the cost modeling infrastructure to support the new functions: - Adds R modeling code to analyze benchmark data and fit cost functions - Includes test cases to verify agreement between R models and Haskell implementation - Supports both ModelTwoArguments and ModelThreeArguments cost function types - Enables automated validation of cost model accuracy This completes the cost modeling pipeline allowing benchmark data to be processed into production-ready cost model coefficients.
Unisay
force-pushed
the
yura/costing-builtin-value
branch
from
2eec71f to
58b2a86
Compare
The original benchmark generation created repeated parameter combinations due to Size enum mapping, causing clustered data points in 3D plots. This hybrid approach maintains all original Size-based systematic tests for guaranteed coverage while adding 100 random tests per function with varied parameters: - LookupCoin: 0-20KB keys, 1-2000 policies, 1-1000 tokens/policy - ValueContains: 1-5000 entries with varied key sizes Random tests bypass the Size system entirely, generating diverse benchmark names like "LookupCoin/1/125/83083" instead of repeated "LookupCoin/4/4/3100" entries, enabling better parameter spread for cost model visualization and analysis.
This refactoring simplifies the benchmarking code by: - Eliminating the intermediate Size datatype that was converting to Int anyway - Using direct Int parameters with numeric underscores for clarity - Expanding abbreviated variable names to improve code readability - Ensuring proper code formatting with line length constraints The changes maintain all existing benchmark logic while making the code more maintainable and easier to understand.
Replace placeholder zero costs with empirically-derived parameters: - lookupCoin: linear model with intercept=269678, slope=1 - valueContains: added_sizes model with intercept=30547830, slope=30 Remove obsolete complexity modeling comments in R file as the implementation now uses proper linear models based on benchmark data.
Add extensive benchmark measurements covering various parameter combinations to support the empirical cost model derivation: - LookupCoin benchmarks with different map sizes and key counts - ValueContains benchmarks with varying value sizes - Additional BLS12-381 multiScalarMul benchmark data for completeness This data was used to derive the cost model parameters committed separately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
This PR implements costing functions for the
lookupCoinandvalueContainsbuilt-in functions in Plutus Core, making them usable in practice by replacing prohibitively expensiveunimplementedCostingFunwith proper cost models.Implementation
✅ Complete Implementation Pipeline
Function Specifications
lookupCoin:ByteString -> ByteString -> Value -> Integer(3 arguments)ModelThreeArgumentswith constant memory modelvalueContains:Value -> Value -> Bool(2 arguments)ModelTwoArgumentswith constant memory modelBenchmarking Highlights
StdGenfor reproducible, deterministic test dataRecent Improvements
Cost Model Approach
Both functions use constant memory models reflecting their O(1) memory characteristics:
Current State
All implementation steps are complete:
The functions are now immediately usable with reasonable costing instead of being prohibitively expensive.