4 ms·

Has anyone given any thought to dynamic linking wasm objects to save bandwidth?

steveklabnik 9y ago
It totally works, it's just not particularly easy to do. wasm modules have import and export sections; you'd instantiate the std module first, the instantiate the module that depends on it, pointing its imports at std's exports. I don't know of any tooling that makes this super easy at the moment though, you basically have to do it by hand as far as I know.
- kodablah 9y ago
  I don't think you can at runtime from wasm though. Imports are resolved at load time. Sure there are call indirect that let you dynamically change the function index but not the import/export. Now if you were willing to reload, you could use the JS API to create modules at runtime with dynamically downloaded pieces, but once created, that's it I think.
  - steveklabnik 9y ago
    Sure, I'm talking about "instantiate one big module" vs "instantiate several smaller modules, then finally the last module". Which is a bit different than what you're talking about; you're right that after you've instantiated, you can't change imports.
- drhodes 9y ago
  great, thanks, that clarifies things quite a bit.
deleted 9y ago
[deleted]
ainar-g 9y ago
I would prefer compilers that produce compact statically linked "binaries".
- bluejekyll 9y ago
  Assuming that the Rust stdlib eventually is compatible/compiled for WASM, wouldn’t it be better if that was cached for all sites which use it, rather than downloading it each time? I can imagine a world where all dependencies are compiled for WASM, similar to crates.io, and then all apps using those libs would benefit from sharing and load blazingly fast because they only load the site specific code. Wouldn’t that be a good thing?
  - sd8dgf8ds8g8dsg 9y ago
    This is what we have CDN:s for
  - Rusky 9y ago
    There are two problems with that, at least for the stdlib. First, the stdlib contains a lot of compiler version-specific code so the savings would not be that great unless (until?) it becomes much more stable, along the lines of glibc. Second, a large portion of stdlib is generics, which are be monomorphized per-app. Further, much of stdlib usage should be inlined and optimized into the app itself anyway. The portions of the stdlib statically linked into an app will generally always be smaller than the whole stdlib. It may make sense to dynamically link some parts of the platform, like the memory allocator, but the whole stdlib is not a good candidate.
    - bluejekyll 9y ago
      That is a great point about the monomorphized code. I hadn’t considered that.
  - josephg 9y ago
    For what its worth, the web community is currently pretty conflicted on using this approach. jQuery is often loaded from CDNs, while React (and friends) are almost always bundled into each app individually. I'd like to say there's a principled reason behind this, but I think the main reason is that the tooling (webpack, browserify) makes it simpler to embed react than use a CDN version. Actual benchmarks are pretty mixed. If you have a cached CDN copy of react it can be a little faster. But if you get a cache miss, the extra overhead of hitting another host to load dependancies is often 10x-100x slower for unlucky users than downloading 80k(?) of additional gzipped javascript. Its especially bad with react because unless you do isomorphic rendering, your page isn't visible at all until react is downloaded. I suspect Rust's stdlib will compress to a similar size (maybe a little bigger), and the speed saving you're hoping for won't really be worth it in practice; even if you get around the monomorphising problem.

It totally works, it's just not particularly easy to do. wasm modules have import and export sections; you'd instantiate the std module first, the instantiate the module that depends on it, pointing its imports at std's exports. I don't know of any tooling that makes this super easy at the moment though, you basically have to do it by hand as far as I know.

kodablah 9y ago
I don't think you can at runtime from wasm though. Imports are resolved at load time. Sure there are call indirect that let you dynamically change the function index but not the import/export. Now if you were willing to reload, you could use the JS API to create modules at runtime with dynamically downloaded pieces, but once created, that's it I think.
- steveklabnik 9y ago
  Sure, I'm talking about "instantiate one big module" vs "instantiate several smaller modules, then finally the last module". Which is a bit different than what you're talking about; you're right that after you've instantiated, you can't change imports.
drhodes 9y ago
great, thanks, that clarifies things quite a bit.

deleted 9y ago

[deleted]

ainar-g 9y ago

I would prefer compilers that produce compact statically linked "binaries".

bluejekyll 9y ago
Assuming that the Rust stdlib eventually is compatible/compiled for WASM, wouldn’t it be better if that was cached for all sites which use it, rather than downloading it each time? I can imagine a world where all dependencies are compiled for WASM, similar to crates.io, and then all apps using those libs would benefit from sharing and load blazingly fast because they only load the site specific code. Wouldn’t that be a good thing?
- sd8dgf8ds8g8dsg 9y ago
  This is what we have CDN:s for
- Rusky 9y ago
  There are two problems with that, at least for the stdlib. First, the stdlib contains a lot of compiler version-specific code so the savings would not be that great unless (until?) it becomes much more stable, along the lines of glibc. Second, a large portion of stdlib is generics, which are be monomorphized per-app. Further, much of stdlib usage should be inlined and optimized into the app itself anyway. The portions of the stdlib statically linked into an app will generally always be smaller than the whole stdlib. It may make sense to dynamically link some parts of the platform, like the memory allocator, but the whole stdlib is not a good candidate.
  - bluejekyll 9y ago
    That is a great point about the monomorphized code. I hadn’t considered that.
- josephg 9y ago
  For what its worth, the web community is currently pretty conflicted on using this approach. jQuery is often loaded from CDNs, while React (and friends) are almost always bundled into each app individually. I'd like to say there's a principled reason behind this, but I think the main reason is that the tooling (webpack, browserify) makes it simpler to embed react than use a CDN version. Actual benchmarks are pretty mixed. If you have a cached CDN copy of react it can be a little faster. But if you get a cache miss, the extra overhead of hitting another host to load dependancies is often 10x-100x slower for unlucky users than downloading 80k(?) of additional gzipped javascript. Its especially bad with react because unless you do isomorphic rendering, your page isn't visible at all until react is downloaded. I suspect Rust's stdlib will compress to a similar size (maybe a little bigger), and the speed saving you're hoping for won't really be worth it in practice; even if you get around the monomorphising problem.