4 ms·
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 exp
by titzer 7y ago
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
- zenlibs 7y agoThank 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/ https://bnjbvr.github.io/perf-wasm-calls/ [2]: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... [3]: http://speed.wasmer.io/comparison/ http://speed.wasmer.io/comparison/
- tom_mellior 7y agoAre 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 ;-))