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.

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

Add bindings for Module.{serialize,deserialize} #43

Merged
merged 1 commit into from
Jul 22, 2020

Conversation

alexcrichton
Copy link
Member

No description provided.

@alexcrichton alexcrichton merged commit eee99af into bytecodealliance:main Jul 22, 2020
@alexcrichton alexcrichton deleted the encoded-module branch July 22, 2020 19:19
@whitequark
Copy link
Contributor

Thanks for adding this--this has improved YoWASP warm startup latency by 60% and allowed me to display a message during cold startup! Especially the latter is a very nice improvement.

@alexcrichton
Copy link
Member Author

Nice! Glad it was able to work so well :)

@whitequark
Copy link
Contributor

One thing I discovered is that performance is a lot better on bare metal than on a VM (in fact warm startup latency regressed on a VM), presumably because the cache is almost 600 MB in size for Yosys. Any idea why it's so huge? A native Yosys binary is ~17 MB; that's dynamically linked with libc and libstdc++ but it's still more than an order of magnitude smaller.

@alexcrichton
Copy link
Member Author

At this point we haven't put in any effort to optimizing the cache format, so there's likely some low hanging fruit. That being said we'll probably never get as small as the wasm file itself. The default wasmtime implementation also runs zstd compression over the cache object, since it should be pretty compressible (but then time is spent decompressing it).

17 -> 600 is pretty huge though, would you be able to open an issue on the wasmtime repo with the wasm file so we can investigate?

@whitequark
Copy link
Contributor

whitequark commented Oct 25, 2020

That being said we'll probably never get as small as the wasm file itself.

That's totally fine. If it expands by a factor of 5× I will be happy, even if it's compared to a native binary and not the wasm file. I just don't want it to expand by a factor of 25×.

The default wasmtime implementation also runs zstd compression over the cache object, since it should be pretty compressible (but then time is spent decompressing it).

I turn that off on purpose to reduce startup latency, since the amount of time spent in zstd is nontrivial.

@whitequark
Copy link
Contributor

17 -> 600 is pretty huge though, would you be able to open an issue on the wasmtime repo with the wasm file so we can investigate?

Done: bytecodealliance/wasmtime#2318

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants