Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[chain] Gas Fee Equation #1828

Open
zivkovicmilos opened this issue Mar 25, 2024 · 1 comment
Open

[chain] Gas Fee Equation #1828

zivkovicmilos opened this issue Mar 25, 2024 · 1 comment
Labels
📦 🌐 tendermint v2 Issues or PRs tm2 related 📦 ⛰️ gno.land Issues or PRs gno.land package related
Milestone
⏭️Next after mainnet

Comments

@zivkovicmilos
Copy link
Member

Description

This effort covers the introduction of a standard gas formula for VM transaction executions.

The majority of this effort is covered in a detailed issue on the Gno repo already.

Having a standard gas fee equation enables estimating transactions, and having deterministic gas usage across gno nodes and transactions.

Successful outcome of this effort:

  • A gas fee equation is defined and implemented for transaction parsing
@zivkovicmilos zivkovicmilos added 📦 🌐 tendermint v2 Issues or PRs tm2 related 📦 ⛰️ gno.land Issues or PRs gno.land package related labels Mar 25, 2024
@Kouteki Kouteki mentioned this issue Apr 11, 2024
Open
@piux2 piux2 mentioned this issue May 30, 2024
Merged
1 task
@Kouteki
Copy link
Contributor

Kouteki commented Oct 16, 2024

Moving this issue out of the Mainnet launch milestone, since we have #1917 in the mainnet launch scope.

thehowl added a commit that referenced this issue Dec 18, 2024
@piux2 @thehowl
feat: gnovm benchmarking tool (#2241)
b91f2fb 
<!-- please provide a detailed description of the changes made in this
pull request. -->

<details><summary>Contributors' checklist...</summary>

- [ x] Added new tests, or not needed, or not feasible
- [ x] Provided an example (e.g. screenshot) to aid review or the PR is
self-explanatory
- [ x] Updated the official documentation or not needed
- [ x] No breaking changes were made, or a `BREAKING CHANGE: xxx`
message was included in the description
- [ x] Added references to related issues and PRs
- [ x] Provided any useful hints for running manual tests
- [ ] Added new benchmarks to [generated
graphs](https://gnoland.github.io/benchmarks), if any. More info
[here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md).
</details>

We build this tool mainly for the following issues

#1826
#1828
#1281
#1973


We could also use it in the following cases. 

#1973
#2222




### `gnobench` benchmarks the time consumed for each VM CPU OpCode and
persistent access to the store, including marshalling and unmarshalling
of realm objects.

## Design consideration

### Minimum Overhead and Footprint

- Constant build flags enable benchmarking.
- Encode operations and measurements in binary.
- Dump to a local file in binary.
- No logging, printout, or network access involved.

### Accuracy

- Pause the timer for storage access while performing VM opcode
benchmarking.
- Measure each OpCode execution in nanoseconds.
- Store access includes the duration for Amino marshalling and
unmarshalling.


It is built on top of @deelawn's design and framework with @jaekwon's
input.
#2073



## Usage

### Simple mode

The benchmark only involves the GnoVM and the persistent store. It
benchmarks the bare minimum components, and the results are isolated
from other components. We use standardize gno contract to perform the
benchmarking.

This mode is the best for benchmarking each major release and/or changes
in GnoVM.

    make opcode
    make storage

### Production mode

It benchmarks the node in the production environment with minimum
overhead.
We can only benchmark with standardize the contract but also capture the
live usage in production environment.
It gives us a complete picture of the node perform.


  1. Build the production node with benchmarking flags:

`go build -tags "benchmarkingstorage benchmarkingops"
gno.land/cmd/gnoland`

2. Run the node in the production environment. It will dump benchmark
data to a benchmark.bin file.

3. call the realm contracts at `gno.land/r/x/benchmark/opcodes` and
`gno.land/r/x/benchmark/storage`

  4. Stop the server after the benchmarking session is complete.

  5. Run the following command to convert the binary dump:

  `gnobench -bin path_to_benchmark_bin`

    it converts the binary dump to results.csv and results_stats.csv.


## Results ( Examples )

The benchmarking results are stored in two files:
  1. The raw results are saved in results.csv.

  | Operation       | Elapsed Time | Disk IO Bytes |
  |-----------------|--------------|---------------|
  | OpEval          | 40333        | 0             |
  | OpPopBlock      | 208          | 0             |
  | OpHalt          | 167          | 0             |
  | OpEval          | 500          | 0             |
  | OpInterfaceType | 458          | 0             |
  | OpPopBlock      | 166          | 0             |
  | OpHalt          | 125          | 0             |
  | OpInterfaceType | 21125        | 0             |
  | OpEval          | 541          | 0             |
  | OpEval          | 209          | 0             |
  | OpInterfaceType | 334          | 0             |



2. The averages and standard deviations are summarized in
results_stats.csv.

  | Operation      | Avg Time | Avg Size | Time Std Dev | Count |
|----------------|----------|----------|--------------|-------|
| OpAdd          | 101      | 0        | 45           | 300   |
| OpAddAssign    | 309      | 0        | 1620         | 100   |
| OpArrayLit     | 242      | 0        | 170          | 700   |
| OpArrayType    | 144      | 0        | 100          | 714   |
| OpAssign       | 136      | 0        | 95           | 2900  |
| OpBand         | 92       | 0        | 30           | 100   |
| OpBandAssign   | 127      | 0        | 62           | 100   |
| OpBandn        | 97       | 0        | 54           | 100   |
| OpBandnAssign  | 125      | 0        | 113          | 100   |
| OpBinary1      | 128      | 0        | 767          | 502   |
| OpBody         | 127      | 0        | 145          | 13700 |

---------

Co-authored-by: Morgan Bazalgette <[email protected]>
omarsy pushed a commit to omarsy/gno that referenced this issue Dec 18, 2024
@piux2 @thehowl @omarsy
feat: gnovm benchmarking tool (gnolang#2241)
338d3dd 
<!-- please provide a detailed description of the changes made in this
pull request. -->

<details><summary>Contributors' checklist...</summary>

- [ x] Added new tests, or not needed, or not feasible
- [ x] Provided an example (e.g. screenshot) to aid review or the PR is
self-explanatory
- [ x] Updated the official documentation or not needed
- [ x] No breaking changes were made, or a `BREAKING CHANGE: xxx`
message was included in the description
- [ x] Added references to related issues and PRs
- [ x] Provided any useful hints for running manual tests
- [ ] Added new benchmarks to [generated
graphs](https://gnoland.github.io/benchmarks), if any. More info
[here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md).
</details>

We build this tool mainly for the following issues

gnolang#1826
gnolang#1828
gnolang#1281
gnolang#1973


We could also use it in the following cases. 

gnolang#1973
gnolang#2222




### `gnobench` benchmarks the time consumed for each VM CPU OpCode and
persistent access to the store, including marshalling and unmarshalling
of realm objects.

## Design consideration

### Minimum Overhead and Footprint

- Constant build flags enable benchmarking.
- Encode operations and measurements in binary.
- Dump to a local file in binary.
- No logging, printout, or network access involved.

### Accuracy

- Pause the timer for storage access while performing VM opcode
benchmarking.
- Measure each OpCode execution in nanoseconds.
- Store access includes the duration for Amino marshalling and
unmarshalling.


It is built on top of @deelawn's design and framework with @jaekwon's
input.
gnolang#2073



## Usage

### Simple mode

The benchmark only involves the GnoVM and the persistent store. It
benchmarks the bare minimum components, and the results are isolated
from other components. We use standardize gno contract to perform the
benchmarking.

This mode is the best for benchmarking each major release and/or changes
in GnoVM.

    make opcode
    make storage

### Production mode

It benchmarks the node in the production environment with minimum
overhead.
We can only benchmark with standardize the contract but also capture the
live usage in production environment.
It gives us a complete picture of the node perform.


  1. Build the production node with benchmarking flags:

`go build -tags "benchmarkingstorage benchmarkingops"
gno.land/cmd/gnoland`

2. Run the node in the production environment. It will dump benchmark
data to a benchmark.bin file.

3. call the realm contracts at `gno.land/r/x/benchmark/opcodes` and
`gno.land/r/x/benchmark/storage`

  4. Stop the server after the benchmarking session is complete.

  5. Run the following command to convert the binary dump:

  `gnobench -bin path_to_benchmark_bin`

    it converts the binary dump to results.csv and results_stats.csv.


## Results ( Examples )

The benchmarking results are stored in two files:
  1. The raw results are saved in results.csv.

  | Operation       | Elapsed Time | Disk IO Bytes |
  |-----------------|--------------|---------------|
  | OpEval          | 40333        | 0             |
  | OpPopBlock      | 208          | 0             |
  | OpHalt          | 167          | 0             |
  | OpEval          | 500          | 0             |
  | OpInterfaceType | 458          | 0             |
  | OpPopBlock      | 166          | 0             |
  | OpHalt          | 125          | 0             |
  | OpInterfaceType | 21125        | 0             |
  | OpEval          | 541          | 0             |
  | OpEval          | 209          | 0             |
  | OpInterfaceType | 334          | 0             |



2. The averages and standard deviations are summarized in
results_stats.csv.

  | Operation      | Avg Time | Avg Size | Time Std Dev | Count |
|----------------|----------|----------|--------------|-------|
| OpAdd          | 101      | 0        | 45           | 300   |
| OpAddAssign    | 309      | 0        | 1620         | 100   |
| OpArrayLit     | 242      | 0        | 170          | 700   |
| OpArrayType    | 144      | 0        | 100          | 714   |
| OpAssign       | 136      | 0        | 95           | 2900  |
| OpBand         | 92       | 0        | 30           | 100   |
| OpBandAssign   | 127      | 0        | 62           | 100   |
| OpBandn        | 97       | 0        | 54           | 100   |
| OpBandnAssign  | 125      | 0        | 113          | 100   |
| OpBinary1      | 128      | 0        | 767          | 502   |
| OpBody         | 127      | 0        | 145          | 13700 |

---------

Co-authored-by: Morgan Bazalgette <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
📦 🌐 tendermint v2 Issues or PRs tm2 related 📦 ⛰️ gno.land Issues or PRs gno.land package related
Projects
🧙‍♂️gno.land core team
Status: Backlog
🚀 main.gno.land launch 🚀
Status: TODO
Milestone
⏭️Next after mainnet
Development

No branches or pull requests
2 participants
@Kouteki @zivkovicmilos