3 ms·

Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power

Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power that was used to compile very same code on millions of computers every day?

__s 9y ago
Sigh... let's have this thread again. Needs to be effectively sandboxed. Modern JS as a compiler target is just as opaque. JIT compilation is a win on energy relative to the energy spent in a slow interpreter. JITing WASM will take less energy than JITing emscripten-js (nevermind the energy to send over the wire)
littlestymaar 9y ago
Downloading a bigger executable wouldn't necessarily be faster actually, it depends on the size difference and the client bandwidth.[1] Additionnally, it wouldn't be portable (executable compiled for desktop wouldn't run on mobile). [1] See this comment : https://news.ycombinator.com/item?id=16171133 https://news.ycombinator.com/item?id=16171133
- Dolores12 9y ago
  What you are saying is that source code is less in size than compiled native code which is nonsense.
  - littlestymaar 9y ago
    First of all I wasn't talking about source code, I was comparing the output of a C/Rust->wasm compiler to the one of a C/Rust->x86 compiler. Since the wasm virtual machine has a JIT, I believe the compilation to wasm isn't too aggressive with optimizations. And since those make the binary bigger, I assume a wasm output would be lighter than an x86 one. I didn't benchmark it though. And if you compare the size of the binary output with the size of the source code, the binary is bigger in many cases because of optimizations (and runtime size, for small programs). Additionally, the source code can be gziped with a good compression factor whereas the binary cannot. Then 99% of the time, the source code is lighter to send over the internet than the compiled binary.

__s 9y ago

Sigh... let's have this thread again. Needs to be effectively sandboxed. Modern JS as a compiler target is just as opaque. JIT compilation is a win on energy relative to the energy spent in a slow interpreter. JITing WASM will take less energy than JITing emscripten-js (nevermind the energy to send over the wire)

littlestymaar 9y ago

Downloading a bigger executable wouldn't necessarily be faster actually, it depends on the size difference and the client bandwidth.[1] Additionnally, it wouldn't be portable (executable compiled for desktop wouldn't run on mobile). [1] See this comment : https://news.ycombinator.com/item?id=16171133 https://news.ycombinator.com/item?id=16171133

Dolores12 9y ago
What you are saying is that source code is less in size than compiled native code which is nonsense.
- littlestymaar 9y ago
  First of all I wasn't talking about source code, I was comparing the output of a C/Rust->wasm compiler to the one of a C/Rust->x86 compiler. Since the wasm virtual machine has a JIT, I believe the compilation to wasm isn't too aggressive with optimizations. And since those make the binary bigger, I assume a wasm output would be lighter than an x86 one. I didn't benchmark it though. And if you compare the size of the binary output with the size of the source code, the binary is bigger in many cases because of optimizations (and runtime size, for small programs). Additionally, the source code can be gziped with a good compression factor whereas the binary cannot. Then 99% of the time, the source code is lighter to send over the internet than the compiled binary.