-
Notifications
You must be signed in to change notification settings - Fork 954
Review precompiles benchmarks to display mgas/s #8495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review precompiles benchmarks to display mgas/s #8495
Conversation
…gas/s Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This output format is more intuitive and useful imo. I think if we need to try to derive gas costs/targets, we can still do so.
evm/src/test/java/org/hyperledger/besu/evm/precompile/Benchmarks.java
Outdated
Show resolved
Hide resolved
evm/src/test/java/org/hyperledger/besu/evm/precompile/Benchmarks.java
Outdated
Show resolved
Hide resolved
@shemnon What do you think of using actual execution time and the gas requirement to get the mgas/s, instead of deriving a theoretical gas cost from execution time, with the assumption that 35 mgas should take 1 second ? My proposal is to update the benchmark output to focus on actual execution performance (e.g., time per call and Mgas/s), rather than estimating the gas cost. |
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
Signed-off-by: ahamlat <ameziane.hamlat@consensys.net>
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
If we are not trying to determine what a precompile should cost then the MGps is a fine metric. But if the gas schedule is up for debate I found the standard burn rate a reasonable proxy. 35 Mgps was an old 2020 era standard and I think we are starting to get pressure for 100 MGps. But the keccak opcode is going to hold us back. |
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
I think we can keep both, then we can use the output for both use cases. I will update the PR. I agree on 100 mgas/s, I will update to that target. |
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
- Add a header to the output Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
I updated the description, and added the output file below. @shemnon @garyschulte feel free to review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net>
PR description
Review precompiles benchmarking to handle both use cases :
This PR adds the benchmark numbers for
KZGPointEval
precompile, and introduces a header section displaying the derived gas formula and system properties, ensuring that precompile performance output is structured and easy to read.The output looks like this with this PR
You can find the whole output attached to this PR #8495 (comment).
Fixed Issue(s)
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew spotlessApply
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests