3 ms·

Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text

by azakai 13y ago

Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip). You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.

modeless 13y ago
My experience has been that emscripten builds are significantly larger than native even after gzip. Templates are of course an issue in native builds too, but native builds are usually less size-constrained than web apps. Sending (minimized) Rust source code, as we do with JavaScript, would result in significantly smaller downloads (and less code to compile) vs. asm.js. Also shipping a standard library with the browser (as JS does) would be another significant reduction.
- azakai 13y ago
  I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip? I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.
  - modeless 13y ago
    It seems to me like making a fast Rust compiler would be an easier problem than making JavaScript run native code fast :) Thanks for the offer of help. Unfortunately I can't send our code, but I just talked to our guy working on emscripten and he said he's already been in touch (though not about code size yet). https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy08/a5LJliGPDPQJ https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy... My impression of emscripten code size might be out of date, I know that development on asm.js has been pretty rapid.
    - emn13 13y ago
      It's not just a question of engineering resources; some problems are intrinsically hard. There may well be things (like floats in css) in rust that make fast compilation hard if not impossible - depending on what exactly you want to achieve. After all, the point is to generate efficient code, so a solution that simply disregards most optimizations isn't an option; and most of the type system is likely unavoidable and/or critical to the optimizer. By contrast, asm.js is fairly simple: All the heavy lifting of compiling has mostly been done - the remaining JS was chosen so that it fairly straightforwardly represents assembler instructions. Decisions about types and what that means for semantics (and safety) have been done, inlining, code rearranging etc. - that's all largely done. In a way, asm.js is assembler with a weird syntax and environment. I really doubt you'd ever get something like Rust (or really most any other statically compiled language) to ever compile as fast, given comparable resources.

by azakai 13y ago

modeless 13y ago

My experience has been that emscripten builds are significantly larger than native even after gzip. Templates are of course an issue in native builds too, but native builds are usually less size-constrained than web apps. Sending (minimized) Rust source code, as we do with JavaScript, would result in significantly smaller downloads (and less code to compile) vs. asm.js. Also shipping a standard library with the browser (as JS does) would be another significant reduction.

azakai 13y ago
I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip? I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.
- modeless 13y ago
  It seems to me like making a fast Rust compiler would be an easier problem than making JavaScript run native code fast :) Thanks for the offer of help. Unfortunately I can't send our code, but I just talked to our guy working on emscripten and he said he's already been in touch (though not about code size yet). https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy08/a5LJliGPDPQJ https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy... My impression of emscripten code size might be out of date, I know that development on asm.js has been pretty rapid.
  - emn13 13y ago
    It's not just a question of engineering resources; some problems are intrinsically hard. There may well be things (like floats in css) in rust that make fast compilation hard if not impossible - depending on what exactly you want to achieve. After all, the point is to generate efficient code, so a solution that simply disregards most optimizations isn't an option; and most of the type system is likely unavoidable and/or critical to the optimizer. By contrast, asm.js is fairly simple: All the heavy lifting of compiling has mostly been done - the remaining JS was chosen so that it fairly straightforwardly represents assembler instructions. Decisions about types and what that means for semantics (and safety) have been done, inlining, code rearranging etc. - that's all largely done. In a way, asm.js is assembler with a weird syntax and environment. I really doubt you'd ever get something like Rust (or really most any other statically compiled language) to ever compile as fast, given comparable resources.