WebAssembly support #16
Comments
|
Hi @nazar-pc. What kind of difficulties do you have with glibc and gmp? We can help. It will be great to keep the work in the upstream repo, so please do send your PR when you think it's ready. |
|
With glibc the issue is that it can't be compiled to wasm, it outputs something like this: From what I found online, musl is a better option when compilation to WASM is needed, since there is simply no implementation for these for wasm32 target. Things are a bit better with I ran it in debug mode and crafted compilation command for Emscripten manually by specifying path to custom build of In general, it seems to be much easier to deal with pure Rust code rather than with C libraries as dependencies. I should add that I'm not a Rust developer and I can barely read it for now 🙂 |
|
So, it works, but performance is (3 iterations)... |
Great. Can you try in release mode? Because GMP isn't the fastest option anyway (#13), we'll need a replacement at some point. Of course it would be great to have a numeric library in Rust but for now it is external. |
|
It is release mode. With compiler optimization options it is already down to ~12 seconds, but I'm not sure it would be possible to go much further after that very easily. |
|
OK. We need to try to build a static musl binary then. |
|
I figured out a relatively straightforward way to compile it, one of the last things is that I have difficulties with cross-language interaction. Any help is very much appreciated: emscripten-core/emscripten#8441 |
|
Awesome! Not sure whether I can be of much help, but I'm really curious what the slowdown will be, if you compile GMP and vdf to WebAssembly, compared to native code. (I've read encouraging numbers about WebAssembly performance, but still: If it's 5 times slower, that makes a WebAssembly vdf 5 times less useful, I guess?) |
|
VDF is surprisingly slow right now, I'll finish tests and docs and will publish to separate repo first. My guess is that it might be related to math with large numbers or something like that (remember, wasm is 32-bit only right now). |
|
To me it sounds like, if that's feasible in your use case, it would be better to somehow expose the native VDF functionality as a foreign function to WebAssembly. Otherwise the speed advantage of a hypothetical attacker has to be multiplied by the WebAssembly slowdown. |
|
@afck WebAssembly is a bit different. It is just like it sounds - assembly for the web. Since there is some interest, here is undocumented (currently) repo that actually works: https://github.com/subspace/vdf/blob/master/src/main.rs If anyone has skills to debug WebAssembly, I would be happy to work on that together, otherwise I'll try to do something myself. |
|
Right, if it needs to run in the browser, there's no way around compiling everything to WebAssembly, of course. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I'm trying to compile VDF library to WebAssembly so that it can be used in Browser and Node.js enviroments for Subspace project.
I'm having a lot of difficulties with this endeavor (some of the major pain points being glibc and gmp libraries), but hoping to get it working eventually.
Would you be interested in having WebAssembly support in this repo, helping in any way or any other thoughts on the topic?
I'd prefer to upstream all the work in this direction so that it can be kept up to date with any changes happening to source code.
The text was updated successfully, but these errors were encountered: