Stream: git-wasmtime

Topic: wasmtime / issue #6835 Wasmtime: refactor the pooling all...

Wasmtime GitHub notifications bot (Aug 11 2023 at 01:55):

github-actions[bot] commented on issue #6835:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Aug 11 2023 at 01:55):

github-actions[bot] commented on issue #6835:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [ ] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [ ] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Aug 11 2023 at 21:45):

github-actions[bot] commented on issue #6835:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:docs"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Aug 14 2023 at 23:13):

fitzgen commented on issue #6835:

Alex is out of office till the end of the week; do you think you could take a look at this @cfallin?

Wasmtime GitHub notifications bot (Aug 15 2023 at 00:00):

cfallin commented on issue #6835:

Alex is out of office till the end of the week; do you think you could take a look at this @cfallin?

I can possibly take a look, but I'm dealing with pretty bad wrist RSI right now and trying to learn to use my machine with voice dictation so it might take quite a lot of time. if it can wait until Alex is back maybe that's better...

Wasmtime GitHub notifications bot (Aug 15 2023 at 00:21):

jameysharp commented on issue #6835:

The first two commits in this PR are tiny enough that I've just reviewed them and would be happy to sign off on them. Unfortunately the third PR is the interesting part and is a little more overwhelming, and I can't say much about it yet.

On a brief skim I can at least say that moving MemoryAllocationIndex into wasmtime_runtime::Memory like you suggest would remove a bunch of changes which just add .1 into various places. (Similarly for table allocations, I assume?) I don't know what other impact that would have so I'm not sure why you didn't go with that option to begin with.

The other thing that jumps out at me is that extracting MemoryPool/TablePool/StackPool to separate modules looks like it might be easy to split out as a separate PR to reduce the amount of churn in this commit.

Wasmtime GitHub notifications bot (Aug 15 2023 at 00:26):

cfallin commented on issue #6835:

I'd be happy to do a live review over Zoom if that would help... I'm just awfully slow at typing right now!

Wasmtime GitHub notifications bot (Aug 16 2023 at 21:11):

fitzgen commented on issue #6835:

FWIW, 25 instantiation benchmarks "improved", while 9 "regressed". I think this is basically all within the noise.

<details>

sequential/default/data_segments.wat
                        time:   [16.207 µs 16.300 µs 16.396 µs]
                        change: [-14.937% -13.832% -12.750%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) high mild
  3 (3.00%) high severe
sequential/pooling/data_segments.wat
                        time:   [4.1824 µs 4.2111 µs 4.2460 µs]
                        change: [-1.4282% +0.2191% +1.7369%] (p = 0.79 > 0.05)
                        No change in performance detected.
Found 7 outliers among 100 measurements (7.00%)
  4 (4.00%) high mild
  3 (3.00%) high severe

parallel/default/data_segments.wat: with 1 thread
                        time:   [16.374 µs 16.470 µs 16.579 µs]
                        change: [-12.172% -10.245% -8.4601%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 13 outliers among 100 measurements (13.00%)
  7 (7.00%) high mild
  6 (6.00%) high severe
parallel/default/data_segments.wat: with 2 threads
                        time:   [22.580 µs 22.767 µs 22.995 µs]
                        change: [-9.2143% -7.3138% -4.8914%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
  6 (6.00%) high mild
  5 (5.00%) high severe
parallel/default/data_segments.wat: with 3 threads
                        time:   [32.501 µs 32.825 µs 33.211 µs]
                        change: [-5.8662% -3.5161% -0.8508%] (p = 0.01 < 0.05)
                        Change within noise threshold.
Found 16 outliers among 100 measurements (16.00%)
  5 (5.00%) high mild
  11 (11.00%) high severe
parallel/default/data_segments.wat: with 4 threads
                        time:   [55.409 µs 56.588 µs 57.990 µs]
                        change: [-6.6418% -3.2057% +0.3236%] (p = 0.08 > 0.05)
                        No change in performance detected.
parallel/pooling/data_segments.wat: with 1 thread
                        time:   [4.2061 µs 4.2405 µs 4.2806 µs]
                        change: [-0.5488% +1.1592% +2.8516%] (p = 0.17 > 0.05)
                        No change in performance detected.
Found 11 outliers among 100 measurements (11.00%)
  9 (9.00%) high mild
  2 (2.00%) high severe
parallel/pooling/data_segments.wat: with 2 threads
                        time:   [4.9711 µs 5.0071 µs 5.0478 µs]
                        change: [+0.0367% +1.6271% +3.1874%] (p = 0.05 < 0.05)
                        Change within noise threshold.
Found 9 outliers among 100 measurements (9.00%)
  6 (6.00%) high mild
  3 (3.00%) high severe
parallel/pooling/data_segments.wat: with 3 threads
                        time:   [5.5409 µs 5.6522 µs 5.8000 µs]
                        change: [+2.4451% +7.1764% +11.976%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 15 outliers among 100 measurements (15.00%)
  7 (7.00%) high mild
  8 (8.00%) high severe
parallel/pooling/data_segments.wat: with 4 threads
                        time:   [6.0691 µs 6.3499 µs 6.7057 µs]
                        change: [-1.7330% +7.2518% +17.575%] (p = 0.13 > 0.05)
                        No change in performance detected.
Found 20 outliers among 100 measurements (20.00%)
  20 (20.00%) high severe

deserialize/deserialize/data_segments.wat
                        time:   [33.431 µs 33.809 µs 34.249 µs]
                        change: [+1.4039% +3.1953% +5.1095%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 12 outliers among 100 measurements (12.00%)
  3 (3.00%) high mild
  9 (9.00%) high severe
deserialize/deserialize_file/data_segments.wat
                        time:   [31.674 µs 31.989 µs 32.413 µs]
                        change: [-1.6587% +0.5155% +3.0517%] (p = 0.66 > 0.05)
                        No change in performance detected.
Found 13 outliers among 100 measurements (13.00%)
  1 (1.00%) high mild
  12 (12.00%) high severe

sequential/default/empty.wat
                        time:   [2.8884 µs 2.9012 µs 2.9153 µs]
                        change: [-13.844% -8.4599% -3.6245%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  2 (2.00%) high mild
  4 (4.00%) high severe
sequential/pooling/empty.wat
                        time:   [2.9106 µs 2.9333 µs 2.9626 µs]
                        change: [-4.1436% -1.5437% +1.6409%] (p = 0.30 > 0.05)
                        No change in performance detected.
Found 13 outliers among 100 measurements (13.00%)
  3 (3.00%) high mild
  10 (10.00%) high severe

parallel/default/empty.wat: with 1 thread
                        time:   [2.9121 µs 2.9299 µs 2.9504 µs]
                        change: [+1.0205% +2.5318% +4.2334%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 17 outliers among 100 measurements (17.00%)
  10 (10.00%) high mild
  7 (7.00%) high severe
parallel/default/empty.wat: with 2 threads
                        time:   [3.2615 µs 3.3018 µs 3.3505 µs]
                        change: [+1.9848% +3.3641% +4.8919%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 14 outliers among 100 measurements (14.00%)
  14 (14.00%) high severe
parallel/default/empty.wat: with 3 threads
                        time:   [3.4042 µs 3.4264 µs 3.4529 µs]
                        change: [+1.3432% +3.2608% +5.7222%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 13 outliers among 100 measurements (13.00%)
  5 (5.00%) high mild
  8 (8.00%) high severe
parallel/default/empty.wat: with 4 threads
                        time:   [3.5997 µs 3.7497 µs 3.9238 µs]
                        change: [-2.5449% +3.1724% +8.8255%] (p = 0.29 > 0.05)
                        No change in performance detected.
Found 18 outliers among 100 measurements (18.00%)
  1 (1.00%) high mild
  17 (17.00%) high severe
parallel/pooling/empty.wat: with 1 thread
                        time:   [2.9411 µs 2.9568 µs 2.9740 µs]
                        change: [-6.8359% -4.3504% -2.0078%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  4 (4.00%) high mild
  4 (4.00%) high severe
parallel/pooling/empty.wat: with 2 threads
                        time:   [3.2878 µs 3.3114 µs 3.3471 µs]
                        change: [-12.572% -10.707% -9.0176%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe
parallel/pooling/empty.wat: with 3 threads
                        time:   [3.4820 µs 3.5166 µs 3.5603 µs]
                        change: [-11.531% -8.9122% -6.6623%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  4 (4.00%) high mild
  5 (5.00%) high severe
parallel/pooling/empty.wat: with 4 threads
                        time:   [3.6409 µs 3.7537 µs 3.8965 µs]
                        change: [-16.527% -11.957% -6.6742%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 19 outliers among 100 measurements (19.00%)
  6 (6.00%) high mild
  13 (13.00%) high severe

deserialize/deserialize/empty.wat
                        time:   [30.528 µs 30.743 µs 31.004 µs]
                        change: [-2.9185% -0.4947% +1.5731%] (p = 0.68 > 0.05)
                        No change in performance detected.
Found 6 outliers among 100 measurements (6.00%)
  4 (4.00%) high mild
  2 (2.00%) high severe
deserialize/deserialize_file/empty.wat
                        time:   [31.130 µs 31.350 µs 31.596 µs]
                        change: [-1.4528% -0.2984% +0.7568%] (p = 0.62 > 0.05)
                        No change in performance detected.
Found 6 outliers among 100 measurements (6.00%)
  5 (5.00%) high mild
  1 (1.00%) high severe

sequential/default/spidermonkey.wasm
                        time:   [17.126 µs 17.343 µs 17.598 µs]
                        change: [-24.108% -23.194% -22.072%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  2 (2.00%) high mild
  3 (3.00%) high severe
sequential/pooling/spidermonkey.wasm
                        time:   [5.6331 µs 5.6638 µs 5.6966 µs]
                        change: [-4.0009% -2.8480% -1.6732%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe

parallel/default/spidermonkey.wasm: with 1 thread
                        time:   [17.304 µs 17.442 µs 17.610 µs]
                        change: [-23.116% -20.805% -18.284%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) high mild
  10 (10.00%) high severe
parallel/default/spidermonkey.wasm: with 2 threads
                        time:   [31.028 µs 31.269 µs 31.553 µs]
                        change: [-1.1847% +0.3038% +1.7367%] (p = 0.68 > 0.05)
                        No change in performance detected.
Found 8 outliers among 100 measurements (8.00%)
  6 (6.00%) high mild
  2 (2.00%) high severe
parallel/default/spidermonkey.wasm: with 3 threads
                        time:   [39.188 µs 39.735 µs 40.395 µs]
                        change: [-14.835% -12.205% -9.7141%] (p = 0.0
[message truncated]

Wasmtime GitHub notifications bot (Aug 17 2023 at 19:12):

fitzgen edited a comment on issue #6835:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [x] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [ ] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Aug 17 2023 at 19:13):

fitzgen edited a comment on issue #6835:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [x] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [x] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Aug 17 2023 at 19:13):

fitzgen edited a comment on issue #6835:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [x] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [x] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [x] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Last updated: Nov 22 2024 at 17:03 UTC