Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

New Function Call Cost Model (Without parameter estimation) #6992

Closed
jakmeier opened this issue Jun 7, 2022 · 3 comments
Closed

New Function Call Cost Model (Without parameter estimation) #6992

jakmeier opened this issue Jun 7, 2022 · 3 comments
Assignees
@jakmeier
Labels
A-params-estimator Area: runtime params estimator T-contract-runtime Team: issues relevant to the contract runtime team

Comments

@jakmeier
Copy link
Contributor

jakmeier commented Jun 7, 2022 •
edited by exalate-issue-sync bot
Loading

This issue is to discuss what the correct gas cost model is for a function call. (Independent of numerical values.)

Today, after some refactoring done already, this is the gas cost for a function call. (Without WASM cost.)

Variables:

  • A: Message size = bytes of method name + argument
  • B: Contract code size in bytes

On the sender side

| Receipt cost | `action_receipt_creation_send` + `action_receipt_creation_exec` + `action_function_call_send` | `action_function_call_per_byte_send` |   |

On the receiver side

| Receipt cost |  `action_function_call_exec` | `action_function_call_per_byte_exec` |   | | Executable Loading | `wasm_contract_loading_base` |   | `wasm_contract_loading_bytes` |

Possible changes

  1. There is an argument for removing wasm_contract_loading_base. It could be absorbed by action_function_call_exec.
  • PRO: One less parameter that is charged in dynamic cost, therefore this cost is no longer limited by prepaid gas added to a function call.
  • CON: Breaks symmetry of send / exec cost for the fn call action, which can be confusing for users. (Presumably, we want to break the symmetry eventually anyway.)
  1. We could split the cost wasm_contract_loading_bytes into storage loading and executable loading.
  • This would allow to charge storage costs slightly earlier in the code but logically there are very few cases where it makes a difference.
  • feat(params-estimator): Cleanup fn call estimation #6362 shows that the storage cost is much smaller. Probably it is not worth it to add a separate cost for it.

Related issues: #6353 #4826
@jakmeier jakmeier added T-contract-runtime Team: issues relevant to the contract runtime team A-params-estimator Area: runtime params estimator labels Jun 7, 2022
@jakmeier jakmeier self-assigned this Jun 7, 2022
@jakmeier
Copy link
Contributor Author

Relevant for this discussion, slides that explain exactly where we charge which fee.

https://docs.google.com/presentation/d/10nqplCDpmLdzeZbVx9POwBqEYH6aSFcZOgZPA2vMK_g/edit?usp=sharing

@jakmeier jakmeier mentioned this issue Jul 21, 2022
Closed
@jakmeier jakmeier mentioned this issue Sep 8, 2022
Merged
near-bulldozer bot pushed a commit that referenced this issue Sep 14, 2022
@jakmeier
feat: prefetch accounts and access keys (#7590)
113f66c 
Introduces the concept of prefetching data from the DB while applying chunks.

This is non-speculative prefetching only for now. In other words, the future is not speculatively predicted, only data is fetched that is guaranteed to be useful. More details on that inside `runtime/runtime/src/prefetch.rs`.

No protocol change is needed for this. In general, prefetching how it has been implemented is (supposed to be) invisible in all possible ways, other than trie storage latency.

Performance wise, this is going to make the worst-case assumption for all action receipts better. The worst case is that two accounts and one access keys have to be fetched from disk for every receipt. This IO cost dominates the gas cost for action receipt creation.

Prefetching this data opens the door to potentially reducing this cost. This could affect all actions but is particularly relevant for redistributing gas costs around function call actions, see also #6992.

----
### Test plan
Tests check that the prefetcher loads the trie nodes that are expected into the staging area and that they are removed from it afterwards.
jakmeier added a commit to jakmeier/nearcore that referenced this issue Sep 15, 2022
@jakmeier
feat: prefetch accounts and access keys (near#7590)
3277435 
Introduces the concept of prefetching data from the DB while applying chunks.

This is non-speculative prefetching only for now. In other words, the future is not speculatively predicted, only data is fetched that is guaranteed to be useful. More details on that inside `runtime/runtime/src/prefetch.rs`.

No protocol change is needed for this. In general, prefetching how it has been implemented is (supposed to be) invisible in all possible ways, other than trie storage latency.

Performance wise, this is going to make the worst-case assumption for all action receipts better. The worst case is that two accounts and one access keys have to be fetched from disk for every receipt. This IO cost dominates the gas cost for action receipt creation.

Prefetching this data opens the door to potentially reducing this cost. This could affect all actions but is particularly relevant for redistributing gas costs around function call actions, see also near#6992.

----

Tests check that the prefetcher loads the trie nodes that are expected into the staging area and that they are removed from it afterwards.
jakmeier added a commit to jakmeier/nearcore that referenced this issue Sep 15, 2022
@jakmeier
feat: prefetch accounts and access keys (near#7590)
0dd0ced 
Introduces the concept of prefetching data from the DB while applying chunks.

This is non-speculative prefetching only for now. In other words, the future is not speculatively predicted, only data is fetched that is guaranteed to be useful. More details on that inside `runtime/runtime/src/prefetch.rs`.

No protocol change is needed for this. In general, prefetching how it has been implemented is (supposed to be) invisible in all possible ways, other than trie storage latency.

Performance wise, this is going to make the worst-case assumption for all action receipts better. The worst case is that two accounts and one access keys have to be fetched from disk for every receipt. This IO cost dominates the gas cost for action receipt creation.

Prefetching this data opens the door to potentially reducing this cost. This could affect all actions but is particularly relevant for redistributing gas costs around function call actions, see also near#6992.

----

Tests check that the prefetcher loads the trie nodes that are expected into the staging area and that they are removed from it afterwards.
@jakmeier
Copy link
Contributor Author

Putting the table in a comment, outside the reach of bots..

Variables:

  • A: Message size = bytes of method name + argument
  • B: Contract code size in bytes

On the sender side

  Base Scaled by message size A Scaled by code size B
Receipt cost action_receipt_creation_send + action_receipt_creation_exec + action_function_call_send action_function_call_per_byte_send  

On the receiver side

  Base Scaled by message size A Scaled by code size B
Receipt cost action_function_call_exec action_function_call_per_byte_exec  
Executable Loading wasm_contract_loading_base   wasm_contract_loading_bytes

@jakmeier
Copy link
Contributor Author

So far it looks like we don't necessarily want to change the set of parameters too much. We probably want to change the parameter values as described in #7227. But this issue for figuring out the set of parameters making up the model can be closed now.

This was referenced Sep 30, 2022
Open
Closed
nikurt pushed a commit that referenced this issue Nov 9, 2022
@jakmeier
feat: prefetch accounts and access keys (#7590)
0d6ad30 
Introduces the concept of prefetching data from the DB while applying chunks.

This is non-speculative prefetching only for now. In other words, the future is not speculatively predicted, only data is fetched that is guaranteed to be useful. More details on that inside `runtime/runtime/src/prefetch.rs`.

No protocol change is needed for this. In general, prefetching how it has been implemented is (supposed to be) invisible in all possible ways, other than trie storage latency.

Performance wise, this is going to make the worst-case assumption for all action receipts better. The worst case is that two accounts and one access keys have to be fetched from disk for every receipt. This IO cost dominates the gas cost for action receipt creation.

Prefetching this data opens the door to potentially reducing this cost. This could affect all actions but is particularly relevant for redistributing gas costs around function call actions, see also #6992.

----
### Test plan
Tests check that the prefetcher loads the trie nodes that are expected into the staging area and that they are removed from it afterwards.
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@jakmeier jakmeier

Labels
A-params-estimator Area: runtime params estimator T-contract-runtime Team: issues relevant to the contract runtime team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jakmeier and others