Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

Re:Not So Fast: Analyzing the Performance of WebAssembly vs.... by titzer on Wednesday July 17, 2019 @08:23AM (#20458639)

Please actually read the paper. As usual, the mean is a poor approximation of a distribution. This paper states repeatedly that it was able to reproduce the experimental results from the 2017 PLDI paper, which primarily used PolyBenchC as the suite. My team wrote that paper. We didn't cherry pick.

The issue is mostly that we suck more on Spec2k6 than we realized. Since publishing that paper we do track Spec2k6 internally but we don't spend time tuning for it.

/v8 wasm runtime TL

[ Parent | on HN ]

Re:Not So Fast: Analyzing the Performance of WebAssembly vs.... by zenlibs on Wednesday July 17, 2019 @12:01PM (#20460886)

Thank you for the clarification. Some questions related to V8 perf:

1. WASM <--> JS/Host calls seem to have a higher cost on chrome than FF [1][2]. Is that in your optimization roadmap?

2. Wasmer tracks V8 perf against other backbends, and the LLVM backend consistently outperforms V8 [3]. Can anything be done to address this, especially for node, where the compile time cost of a super optimizing compiler might be beneficial in certain applications?

[1]: https://bnjbvr.github.io/perf-wasm-calls/

[2]: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

[3]: http://speed.wasmer.io/comparison/

[ Parent | on HN ]

Re:Not So Fast: Analyzing the Performance of WebAssembly vs.... by tom_mellior on Wednesday July 17, 2019 @12:29PM (#20461249)

Are you looking into some of the issues raised in the paper? Better use of register-memory instructions seems like it might be a relatively big win for relatively little effort.

The code in lines 35-37 in Figure 7(c) looks like you should be able to fold the memory operand even in a simple peephole pass before register allocation, no? (I know, I know, patches are probably welcome ;-))

[ Parent | on HN ]