profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/alexcrichton/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

alexcrichton/AudioStreamer 70

A streaming audio player class (AudioStreamer) for Mac OS X and iPhone.

alexcrichton/bzip2-rs 56

libbz2 (bzip2 compression) bindings for Rust

alexcrichton/bufstream 30

A buffered I/O stream for Rust

alexcrichton/ars 1

ar in Rust

alexcrichton/atty 1

are you or are you not a tty?

alexcrichton/binaryen 1

Compiler infrastructure and toolchain library for WebAssembly, in C++

alexcrichton/bzip2-ruby 1

Original libbz2 ruby C bindings from Guy Decoux, with some new love

alexcrichton/1password-teams-open-source 0

Get a free 1Password Teams membership for your open source project

push eventbytecodealliance/wasmtime-py

Deploy from CI

commit sha d1917b587f5a4a198a10f9ae3f002eae861350f5

Deploy 9174479db85f8c956299de761fbbcffcfd25771d to gh-pages

view details

push time in a day

push eventbytecodealliance/wasmtime

Deploy from CI

commit sha 5700cae4671fad6da84aceab6fb61b4e86facfac

Deploy 98831fe4e246f7ea00ce10d337cef285841c5e17 to gh-pages

view details

push time in a day

PR opened bytecodealliance/wasmtime-cpp

Bind the new `*_unchecked` function APIs

This commit binds two new APIs added to wasmtime's C API recently:

  • wasmtime_func_new_unchecked
  • wamstime_func_call_unchecked

These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's Func::wrap and Func::typed for statically-typed function calls.

Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the *_unchecked variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

+786 -45

0 comment

8 changed files

pr created time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha aba96d050bfca826f63ef87d78c5c1b2eadc1e34

Bind the new `*_unchecked` function APIs This commit binds two new APIs added to `wasmtime`'s C API recently: * `wasmtime_func_new_unchecked` * `wamstime_func_call_unchecked` These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's `Func::wrap` and `Func::typed` for statically-typed function calls. Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the `*_unchecked` variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 4b57349399533060bff11384d6d0e0a07227fb2a

Bind the new `*_unchecked` function APIs This commit binds two new APIs added to `wasmtime`'s C API recently: * `wasmtime_func_new_unchecked` * `wamstime_func_call_unchecked` These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's `Func::wrap` and `Func::typed` for statically-typed function calls. Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the `*_unchecked` variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

view details

push time in a day

push eventbytecodealliance/wasmtime-py

Alex Crichton

commit sha 9174479db85f8c956299de761fbbcffcfd25771d

Re-run bindgen.py

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha fc69055d4f2be788ff05a287d487309c27db1c90

Bind the new `*_unchecked` function APIs This commit binds two new APIs added to `wasmtime`'s C API recently: * `wasmtime_func_new_unchecked` * `wamstime_func_call_unchecked` These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's `Func::wrap` and `Func::typed` for statically-typed function calls. Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the `*_unchecked` variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

view details

push time in a day

delete branch alexcrichton/wasmtime

delete branch : update-zeroize

delete time in a day

push eventbytecodealliance/wasmtime

Alex Crichton

commit sha 98831fe4e246f7ea00ce10d337cef285841c5e17

Update zeroize_derive to fix a rustsec warning (#3389) Should hopefully appease CI

view details

push time in a day

PR merged bytecodealliance/wasmtime

Update zeroize_derive to fix a rustsec warning

Should hopefully appease CI

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+2 -2

0 comment

1 changed file

alexcrichton

pr closed time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha fabadb0ea78aca3f70685e949fb9b91d45b4a01a

Bind the new `*_unchecked` function APIs This commit binds two new APIs added to `wasmtime`'s C API recently: * `wasmtime_func_new_unchecked` * `wamstime_func_call_unchecked` These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's `Func::wrap` and `Func::typed` for statically-typed function calls. Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the `*_unchecked` variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha c512ea09f1f1d478bf57848a0d1094fc0ded7cef

Don't require docs for now Documenting all the template specialization bits seems... not useful

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 5f520fdab8804beaa33e81c43332adb93166cdc5

Bind the new `*_unchecked` function APIs This commit binds two new APIs added to `wasmtime`'s C API recently: * `wasmtime_func_new_unchecked` * `wamstime_func_call_unchecked` These two functions are a more accelerated path of invoking a WebAssembly function and having a WebAssembly function call the host. The new APIs are generally unsafe but with the C++ bindings added here they should at least be type-safe. The goal was to add APIs similar to the Rust crate's `Func::wrap` and `Func::typed` for statically-typed function calls. Overall the performance here worked out great in that it's on-par with C and as expected from the PR adding the `*_unchecked` variants. This is, however, basically my first foray into templated functions in C++ and wow is this a lot more complicated than I thought that it would be. Some extra eyes on this would be appreciated to see if I've missed something or if the design could be simplified.

view details

Alex Crichton

commit sha 39fc1531fd7da5a1c8d94309680d1b2c70410217

maybe fix

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha d175fb375c56f806501c92cad6aaba437d3ee70b

Suppress some lints

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 07552b8d23c7c7a8ddf850931b4230d717f8bdf5

Format

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 29ae36a9338c03286f947c39e9558c0b974b6199

Fix a segfault

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha a34a21bb65f41180935a00951bec5a8723411032

Remove unused variable

view details

Alex Crichton

commit sha c397a40ffc13d332419f08f41cce3fee7b33b54a

Fix tidy warning

view details

Alex Crichton

commit sha fe78d31b32e0de3e70afa7c39fc8c20860045b2a

Use std::array

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 8c8b57cce99e56b96863457e660a85ad49aff841

Formatting

view details

Alex Crichton

commit sha bc4075cb2fbc8b034a247be015449cd8b4982dc9

Docs and fix msvc

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha ab63f9dfb3675b9eae2154e142e731ff9ca41800

More appeasement of gcc

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 82047c478f3341a24a6f9f2ea4fa8bba29fc95ce

Attempt to appease gcc

view details

Alex Crichton

commit sha ca231d24015cc65b1e37df6bc951d7d7ecf354df

Initialize some fields

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha ba73eafaf5e1971c482b47a79bb0e5f457bde17a

again

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 45147cd3bec161bf862e324d25798cc54db970ab

no-fail-fast

view details

push time in a day

push eventalexcrichton/wasmtime-cpp

Alex Crichton

commit sha 100ce8970971625ec678986d2457b455071f71fc

bump

view details

push time in a day

push eventbytecodealliance/wasmtime

Deploy from CI

commit sha ed316f56d7c9edfbbd2f4ca8cce291de5fecc73b

Deploy bfdbd10a13ec52b7667754000f14b5ef5f5c1c8c to gh-pages

view details

push time in a day

PR opened bytecodealliance/wasmtime

Update zeroize_derive to fix a rustsec warning

Should hopefully appease CI

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+2 -2

0 comment

1 changed file

pr created time in a day

create barnchalexcrichton/wasmtime

branch : update-zeroize

created branch time in a day

delete branch alexcrichton/wasmtime

delete branch : expose-raw

delete time in a day

push eventbytecodealliance/wasmtime

Alex Crichton

commit sha bfdbd10a13ec52b7667754000f14b5ef5f5c1c8c

Add `*_unchecked` variants of `Func` APIs for the C API (#3350) * Add `*_unchecked` variants of `Func` APIs for the C API This commit is what is hopefully going to be my last installment within the saga of optimizing function calls in/out of WebAssembly modules in the C API. This is yet another alternative approach to #3345 (sorry) but also contains everything necessary to make the C API fast. As in #3345 the general idea is just moving checks out of the call path in the same style of `TypedFunc`. This new strategy takes inspiration from previously learned attempts effectively "just" exposes how we previously passed `*mut u128` through trampolines for arguments/results. This storage format is formalized through a new `ValRaw` union that is exposed from the `wasmtime` crate. By doing this it made it relatively easy to expose two new APIs: * `Func::new_unchecked` * `Func::call_unchecked` These are the same as their checked equivalents except that they're `unsafe` and they work with `*mut ValRaw` rather than safe slices of `Val`. Working with these eschews type checks and such and requires callers/embedders to do the right thing. These two new functions are then exposed via the C API with new functions, enabling C to have a fast-path of calling/defining functions. This fast path is akin to `Func::wrap` in Rust, although that API can't be built in C due to C not having generics in the same way that Rust has. For some benchmarks, the benchmarks here are: * `nop` - Call a wasm function from the host that does nothing and returns nothing. * `i64` - Call a wasm function from the host, the wasm function calls a host function, and the host function returns an `i64` all the way out to the original caller. * `many` - Call a wasm function from the host, the wasm calls host function with 5 `i32` parameters, and then an `i64` result is returned back to the original host * `i64` host - just the overhead of the wasm calling the host, so the wasm calls the host function in a loop. * `many` host - same as `i64` host, but calling the `many` host function. All numbers in this table are in nanoseconds, and this is just one measurement as well so there's bound to be some variation in the precise numbers here. | Name | Rust | C (before) | C (after) | |-----------|------|------------|-----------| | nop | 19 | 112 | 25 | | i64 | 22 | 207 | 32 | | many | 27 | 189 | 34 | | i64 host | 2 | 38 | 5 | | many host | 7 | 75 | 8 | The main conclusion here is that the C API is significantly faster than before when using the `*_unchecked` variants of APIs. The Rust implementation is still the ceiling (or floor I guess?) for performance The main reason that C is slower than Rust is that a little bit more has to travel through memory where on the Rust side of things we can monomorphize and inline a bit more to get rid of that. Overall though the costs are way way down from where they were originally and I don't plan on doing a whole lot more myself at this time. There's various things we theoretically could do I've considered but implementation-wise I think they'll be much more weighty. * Tweak `wasmtime_externref_t` API comments

view details

push time in a day

PR merged bytecodealliance/wasmtime

Add `*_unchecked` variants of `Func` APIs for the C API wasmtime:api wasmtime:c-api wasmtime:ref-types

This commit is what is hopefully going to be my last installment within the saga of optimizing function calls in/out of WebAssembly modules in the C API. This is yet another alternative approach to #3345 (sorry) but also contains everything necessary to make the C API fast. As in #3345 the general idea is just moving checks out of the call path in the same style of TypedFunc.

This new strategy takes inspiration from previously learned attempts effectively "just" exposes how we previously passed *mut u128 through trampolines for arguments/results. This storage format is formalized through a new ValRaw union that is exposed from the wasmtime crate. By doing this it made it relatively easy to expose two new APIs:

  • Func::new_unchecked
  • Func::call_unchecked

These are the same as their checked equivalents except that they're unsafe and they work with *mut ValRaw rather than safe slices of Val. Working with these eschews type checks and such and requires callers/embedders to do the right thing.

These two new functions are then exposed via the C API with new functions, enabling C to have a fast-path of calling/defining functions. This fast path is akin to Func::wrap in Rust, although that API can't be built in C due to C not having generics in the same way that Rust has.

For some benchmarks, the benchmarks here are:

  • nop - Call a wasm function from the host that does nothing and returns nothing.
  • i64 - Call a wasm function from the host, the wasm function calls a host function, and the host function returns an i64 all the way out to the original caller.
  • many - Call a wasm function from the host, the wasm calls host function with 5 i32 parameters, and then an i64 result is returned back to the original host
  • i64 host - just the overhead of the wasm calling the host, so the wasm calls the host function in a loop.
  • many host - same as i64 host, but calling the many host function.

All numbers in this table are in nanoseconds, and this is just one measurement as well so there's bound to be some variation in the precise numbers here.

Name Rust C (before) C (after)
nop 19 112 25
i64 22 207 32
many 27 189 34
i64 host 2 38 5
many host 7 75 8

The main conclusion here is that the C API is significantly faster than before when using the *_unchecked variants of APIs. The Rust implementation is still the ceiling (or floor I guess?) for performance The main reason that C is slower than Rust is that a little bit more has to travel through memory where on the Rust side of things we can monomorphize and inline a bit more to get rid of that. Overall though the costs are way way down from where they were originally and I don't plan on doing a whole lot more myself at this time. There's various things we theoretically could do I've considered but implementation-wise I think they'll be much more weighty.

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+657 -215

2 comments

16 changed files

alexcrichton

pr closed time in a day

delete branch alexcrichton/witx-bindgen

delete branch : fix-namign

delete time in a day