You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ref-fvm is currently using the numbers from the first round of benchmarking (on an i7-1185G laptop). The final benchmarks were re-run on an AMD EPYC 7402P, but the ref-fvm was never updated to reflect this.
We have a two options:
Keep the current numbers, update the FIP.
Fix the gas numbers in the ref-fvm in the next network version.
I kind of want to just update the FIP. We don't need any "security margin" here because that's built into the block time itself (there's more variability in block validation time from tipset size than anything we can do here).
The text was updated successfully, but these errors were encountered:
@Stebalien I trust your judgement but since these differences are significant (over 2x for some operations), should we give more details on the tradeoff here? Ideally we would be able to show using a few examples the % diff of using old vs new set of numbers and present conclusions like: "In example X of calling a contract function F, this change resulted in a negligible 2% increase of the overall cost".
From the original FIP, we expected the numbers in the FIP to have a ~5% overhead and expected the current numbers to have a 2.5% overhead for state reads. No overhead for compute and/or state writes. So the actual impact is likely less than 1-2% any which way we go.
I looked at some multisig messages (due to a complaint on slack) but didn't actually see any pattern (some were more expensive, some less, even for virtually identical messages to the same multisig).
Same for "change owner" calls on the miner actor. I'd have to average a lot of messages to get a good number out of this.
The ref-fvm is currently using the numbers from the first round of benchmarking (on an i7-1185G laptop). The final benchmarks were re-run on an AMD EPYC 7402P, but the ref-fvm was never updated to reflect this.
We have a two options:
I kind of want to just update the FIP. We don't need any "security margin" here because that's built into the block time itself (there's more variability in block validation time from tipset size than anything we can do here).
The text was updated successfully, but these errors were encountered: