Skip to content

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

Merged
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
alexcrichton:encoded-module
Jul 22, 2020
Merged

Add bindings for Module.{serialize,deserialize}#43
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
alexcrichton:encoded-module

Conversation

@alexcrichton
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Member Author

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

@whitequark
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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