Stream: git-wasmtime

Topic: wasmtime / issue #5111 Add Config::fuel_cost to customize...

Wasmtime GitHub notifications bot (Oct 24 2022 at 22:52):

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

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 (Oct 24 2022 at 22:52):

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

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 (Oct 26 2022 at 22:43):

coolreader18 commented on issue #5111:

Hmm, should I use saturating_add for adding self.fuel_cost += fuel_cost()? An overflow there would probably be bad, I assume.

Wasmtime GitHub notifications bot (Oct 28 2022 at 13:36):

pepyakin commented on issue #5111:

I wonder how this interacts with the AOT compilation.

Consider that the user creates the engine with a specific fuel cost function, then loads a module, and then serializes it into a file.

Then, perhaps in another version of the program, changes the fuel cost function and loads the previously serialized module. However, the fuel behavior that the loaded module exhibits will be different from the configured fuel costs. I would argue that this is an unexpected behavior. At the very least, I would expect to get an error during the module loading.

To do so, the metadata for the compiled artifact should embed the module costs, but that's not really possible with a closure.

It seems to me that the costs schedule would better be represented, conceptually, by a BTreeMap<Opcode, u32>. That way, you could serialize and embed them into the compiled artifact.

Wasmtime GitHub notifications bot (Oct 31 2022 at 14:49):

alexcrichton commented on issue #5111:

Thanks for the PR here! Could you expand a bit more on the use case that you're envisioning for this? This is a pretty low-level degree of control to give from an embedding API around fuel and feels like a relatively large addition with the enum addition here (not that there's a better way to model this that I know of). I'm curious though if there's perhaps an alternative solution which doesn't expose such low-level control of the fuel costs, but there may not be.

I would also be slightly concerned about the AOT-story here since in theory the costs all need to be equivalent, but that can also be "patched" by returning an error and disabling serialization if this Config field is configured.

Wasmtime GitHub notifications bot (Nov 01 2022 at 16:58):

coolreader18 commented on issue #5111:

Oh, I missed that Module::deserialize checks that the engine configs are the same; those are good points about AOT. Maybe fuel_cost() could take a data structure like rust-unic's CharDataTable or something.

In any case, the motivating use case was switching an existing runtime from wasmer, which has cost customization by default as part of its metering instrumentation and so we were utilizing that. I suppose it is worth looking into how valuable that actually is, when obviously the wasm doesn't map one-to-one to machine code anyway...

Wasmtime GitHub notifications bot (Nov 03 2022 at 17:08):

alexcrichton commented on issue #5111:

Ok makes sense. I think we could have a compiled representation of the costs but that's somewhat overkill and probably not worth implementing. That's one reason why I was wondering what the purpose was for changing costs because if the default wasn't suitable for your use case one option is to either change the defaults or otherwise have various discrete cost modes which would avoid serializing large maps.

Wasmtime GitHub notifications bot (Nov 07 2022 at 21:32):

coolreader18 commented on issue #5111:

That makes sense, I'll look at sketching out a simpler (configuration-wise) solution to this or probably just reworking fuel usage in our codebase. Thank you for your help!

Wasmtime GitHub notifications bot (Nov 07 2022 at 21:41):

jameysharp commented on issue #5111:

In case you haven't already seen it, I'll mention that Wasmtime's "epoch interruption" may be a good alternative to fuel, depending on what you're using it for. From the documentation:

In general, epoch-based interruption results in faster execution. This difference is sometimes significant: in some measurements, up to 2-3x. This is because epoch-based interruption does less work: it only watches for a global rarely-changing counter to increment, rather than keeping a local frequently-changing counter and comparing it to a deadline.

Fuel, in contrast, should be used when deterministic yielding or trapping is needed. For example, if it is required that the same function call with the same starting state will always either complete or trap with an out-of-fuel error, deterministically, then fuel with a fixed bound should be used.

Last updated: Nov 22 2024 at 17:03 UTC