4 ms·

This whole reply doesn't pass the smell test. > Web Assembly targets C and C++ as source languages, unlike the JVM. So wasm (and hence JavaScript if you trans

This whole reply doesn't pass the smell test. > Web Assembly targets C and C++ as source languages, unlike the JVM. So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true. > Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow. Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all. Once you add gc into wasm, it is almost guaranteed to be closer to java than c/c++.

pcwalton 9y ago
> So wasm…are closer c/c++ than to java? Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has. > Considering all the UB in C, this cannot possibly be true. Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be relatively free of undefined behavior. > Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all. I would highly doubt it's performance competitive at the level that browsers are at now. It strikes me as likely impossible to get performance competitive on, say, SunSpider if you aren't highly tuned for it.
- jnordwick 9y ago
  Nashorn is anywhere to faster on primitive heavy computation to 50% slower post JIT. Graal is supposed to be even faster. > Web Assembly has unsigned integer arithmetic This is your idea of a major difference that affects implementation so much that is separate VM needs to be written? Many Java programs already do essentially manual memory management already too. Those aren't the big differences. Things like safe-memory access are bigger issues. And once wasm gets gc, it will even be closer to Java and JS. I hope Graal outperforms everything else, so we can stop pretending like WASM is something different than what Java has been trying to do.

pcwalton 9y ago

> So wasm…are closer c/c++ than to java? Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has. > Considering all the UB in C, this cannot possibly be true. Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be relatively free of undefined behavior. > Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all. I would highly doubt it's performance competitive at the level that browsers are at now. It strikes me as likely impossible to get performance competitive on, say, SunSpider if you aren't highly tuned for it.

jnordwick 9y ago
Nashorn is anywhere to faster on primitive heavy computation to 50% slower post JIT. Graal is supposed to be even faster. > Web Assembly has unsigned integer arithmetic This is your idea of a major difference that affects implementation so much that is separate VM needs to be written? Many Java programs already do essentially manual memory management already too. Those aren't the big differences. Things like safe-memory access are bigger issues. And once wasm gets gc, it will even be closer to Java and JS. I hope Graal outperforms everything else, so we can stop pretending like WASM is something different than what Java has been trying to do.