How much of this performance gap is due to the inherent limitations of the WebAssembly technology, and how much is due to it being relatively new? I.e., do we expect to see performance improvements similar to what we've seen in JavaScript over the last two decades? Or are we going to need better hardware to realize better performance?
> It is worth asking if the performance issues identified hereare fundamental. We believe that two of the identified issues are not: that is, they could be ameliorated by improved implementations. WebAssembly implementations today useregister allocators (§6.1.2) and code generators (§6.2.1) thatperform worse than Clang’s counterparts. However, an offlinecompiler like Clang can spend considerably more time togenerate better code, whereas WebAssembly compilers mustbe fast enough to run online. Therefore, solutions adoptedby other JITs, such as further optimizing hot code, are likely applicable here.
> The four other issues that we have identified appear to arise from the design constraints of WebAssembly: the stackoverflow checks (§6.2.2), indirect call checks (§6.2.3), andreserved registers (§6.1.1) have a runtime cost and lead to in-creased code size (§6.3). Unfortunately, these checks are nec-essary for WebAssembly’s safety guarantees. A redesigned WebAssembly, with richer types for memory and function pointers [23], might be able to perform some of these checksat compile time, but that could complicate the implementation of compilers that produce WebAssembly. Finally, a Web-Assembly implementation in a browser must interoperate witha high-performance JavaScript implementation, which mayimpose its own constraints. For example, current JavaScript implementations reserve a few registers for their own use,which increases register pressure on WebAssembly.