27 ms·

I am still a little bit disappointed that most transpiled languages have to provide a litte operating system to run their code including memory management and g

I am still a little bit disappointed that most transpiled languages have to provide a litte operating system to run their code including memory management and garbage collection. With this overhead webassembly can be even much slower than Javascript (downloading, compilation, simplified but slow memory management). If I remember correctly Rust adds 200kB of code to the webassembly binary. For me it was only possible to produce small binaries with emscripten C without any includes (bare metal). The proposals look promising and might reduce this overhead somewhat. However I don't think they will manage to design the virtual machine that is able to run all major rogramming languages efficiently. What ab0out features such as longjmp and goto in C?

steveklabnik 8y ago
That is incorrect; the smallest rust produced binary is ~100 bytes. Only the code you use is included; if you want an allocator, choosing a smaller one is a good idea, for example. We are usually significantly smaller than emscripten for the same code.
- s-macke 8y ago
  I just programmed a function, which added 2 numbers and compiled it and got a huge binary. But maybe I did something wrong. I will try again. Thanks.
  - the_duke 8y ago
    Which target are you using?
    - s-macke 8y ago
      I can tell you in a few hours. But it would be easier if you provide me the correct compile options to produce such a small binary for trivial functions. Target was of course the webassembly target.
      - steveklabnik 8y ago
        There's two wasm targets; one with emscripten, one without. It sounds like you were using the one without, which is generally the right one.
  - ColinEberhardt 8y ago
    the tooling is quite immature at the moment - and tools like Emscripten especially add a lot of bloat. In the future wasm modules will be a lot slimmer. The Rust community are certainly leading the way on that one.
  - maeln 8y ago
    I you did the naive add two number example, you probably also included the whole standard library. If you really want to go down in size, you either need to compile without the standard library and/or use wasm-gc and wasmopt to remove all the useless code that have been added to your wasm binary. With this, you can generate wasm binary that weight only a few hundreds octets.
  - steveklabnik 8y ago
    There's a lot of stuff going on. Depending on which rust you used, we didn't do a lot of dead code elimination by default, and the default settings don't optimize for size. The 100 byte thing is the "add two numbers" function, but you have to do a few things. See here: https://rustwasm.github.io/book/game-of-life/code-size.html https://rustwasm.github.io/book/game-of-life/code-size.html In the future, it will do more of the right things by default, but for now, you have to do some configuration if you want the tiniest possible binary. Early days!
- s-macke 8y ago
  In C for webassembly I can access the provided memory directly, which leads to the following unusual code. char *m = NULL; m[1] = 0xFF; For m[0] the compiler exchanges the code with the abort function :-) I wonder, if something similar is possible in Rust.
  - steveklabnik 8y ago
    I haven't tried it, but it should do the same thing.
- azakai 8y ago
  I think Rust and C/C++ are in the same boat here: both can produce tiny wasm binaries of 100 bytes or less. Here's a post about Emscripten generating a 42 byte binary from C: https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-javascript-code-sizes-in-emscripten/ https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-... But yeah, as you and others said, while both Rust and C/C++ can do that, there's a lot more going on in the general case. Once you add a malloc/free implementation, or string operations, or anything else, the size increases. The fundamental issue is that Rust and C/C++ were not designed for this use case. In principle, a new language could do a lot better. If such a language were GC based, it would avoid shipping a malloc/free (once wasm gets GC, that will be "free" for that language). And if such a language had the same string types and a compatible "standard library" with the Web, so that it would just call directly into existing Web APIs, then it would avoid shipping a lot of other code that Rust and C/C++ currently need. TypeScript, for example, could become such a language. That would probably be the optimal path for creating tiny wasm binaries.
  - steveklabnik 8y ago
    They’ve been working on binary size, and it shows. I didn’t know it went so far already; last I checked it was much bigger. I’ll update that fact in my brain, thank you! I’m not as convinced as you regarding such a language, for example, once host bindings lands, you’ll be able to call into every API with no overhead, and the bindgen stuff we’re doing will transparently just shrink overnight. But we’ll see! It’s exciting times.
  - Touche 8y ago
    There's an existing project to compile TypeScript to wasm (I haven't used it, not sure about its file size): https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript
    - azakai 8y ago
      Yeah, AssemblyScript is great! Huge potential there.

steveklabnik 8y ago

That is incorrect; the smallest rust produced binary is ~100 bytes. Only the code you use is included; if you want an allocator, choosing a smaller one is a good idea, for example. We are usually significantly smaller than emscripten for the same code.

s-macke 8y ago
I just programmed a function, which added 2 numbers and compiled it and got a huge binary. But maybe I did something wrong. I will try again. Thanks.
- the_duke 8y ago
  Which target are you using?
  - s-macke 8y ago
    I can tell you in a few hours. But it would be easier if you provide me the correct compile options to produce such a small binary for trivial functions. Target was of course the webassembly target.
    - steveklabnik 8y ago
      There's two wasm targets; one with emscripten, one without. It sounds like you were using the one without, which is generally the right one.
- ColinEberhardt 8y ago
  the tooling is quite immature at the moment - and tools like Emscripten especially add a lot of bloat. In the future wasm modules will be a lot slimmer. The Rust community are certainly leading the way on that one.
- maeln 8y ago
  I you did the naive add two number example, you probably also included the whole standard library. If you really want to go down in size, you either need to compile without the standard library and/or use wasm-gc and wasmopt to remove all the useless code that have been added to your wasm binary. With this, you can generate wasm binary that weight only a few hundreds octets.
- steveklabnik 8y ago
  There's a lot of stuff going on. Depending on which rust you used, we didn't do a lot of dead code elimination by default, and the default settings don't optimize for size. The 100 byte thing is the "add two numbers" function, but you have to do a few things. See here: https://rustwasm.github.io/book/game-of-life/code-size.html https://rustwasm.github.io/book/game-of-life/code-size.html In the future, it will do more of the right things by default, but for now, you have to do some configuration if you want the tiniest possible binary. Early days!
s-macke 8y ago
In C for webassembly I can access the provided memory directly, which leads to the following unusual code. char *m = NULL; m[1] = 0xFF; For m[0] the compiler exchanges the code with the abort function :-) I wonder, if something similar is possible in Rust.
- steveklabnik 8y ago
  I haven't tried it, but it should do the same thing.
azakai 8y ago
I think Rust and C/C++ are in the same boat here: both can produce tiny wasm binaries of 100 bytes or less. Here's a post about Emscripten generating a 42 byte binary from C: https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-javascript-code-sizes-in-emscripten/ https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-... But yeah, as you and others said, while both Rust and C/C++ can do that, there's a lot more going on in the general case. Once you add a malloc/free implementation, or string operations, or anything else, the size increases. The fundamental issue is that Rust and C/C++ were not designed for this use case. In principle, a new language could do a lot better. If such a language were GC based, it would avoid shipping a malloc/free (once wasm gets GC, that will be "free" for that language). And if such a language had the same string types and a compatible "standard library" with the Web, so that it would just call directly into existing Web APIs, then it would avoid shipping a lot of other code that Rust and C/C++ currently need. TypeScript, for example, could become such a language. That would probably be the optimal path for creating tiny wasm binaries.
- steveklabnik 8y ago
  They’ve been working on binary size, and it shows. I didn’t know it went so far already; last I checked it was much bigger. I’ll update that fact in my brain, thank you! I’m not as convinced as you regarding such a language, for example, once host bindings lands, you’ll be able to call into every API with no overhead, and the bindgen stuff we’re doing will transparently just shrink overnight. But we’ll see! It’s exciting times.
- Touche 8y ago
  There's an existing project to compile TypeScript to wasm (I haven't used it, not sure about its file size): https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript
  - azakai 8y ago
    Yeah, AssemblyScript is great! Huge potential there.