Closed hexpunk closed 2 years ago
Yeah, massive hasn't been updated with recent wasm changes. I'm not sure it's worth doing right now, as we also need to change massive in some ways (for async startup, we need to measure startup differently) - probably we should rethink how we benchmark as a whole.
What would be the simplest way to get box2d benchmark working in wasm mode? Is it just a matter of recompiling with new version of emscripten?
By chance I just finished updating box2d.js to wasm, see the wasm branch in that repo, it now has both asm.js and wasm builds. Just using them here should work - but as mentioned above, just for throughput, startup measurements may be meaningless.
Thanks. I tried that but I looks like I am missing some source code or trying to do the wrong stuff. If I just use files from the new box2d.js build, I don't get any output into Module.printBuffer. I suspect there should be some code that runs the actual benchmark and prints a string like "frame averages: 31.675 +- 7.808, range: 22.000 to 63.000" but I am unable to find that code. Do you have any hints perhaps?
Hmm, yes, reading driver.js, it says https://github.com/kripken/Massive/blob/master/driver.js#L113 "let the emscripten benchmark suite generate it for you". So running something like python tests/runner.py benchmark.test_zzz_box2d
in emscripten should emit it.
If we create some JS to run the benchmark, and use box2d.js, that would also measure the overhead of calling from JS into compiled code, which might or might not make sense to do, depends what you want.
There are builds from the emscripten benchmark here, btw, including box2d https://github.com/kripken/embenchen/tree/master/asm_v_wasm
no native wasm support detected box2d.js:337:4
Doesn't detect it on Firefox 55.
This test is one of the top Google results for "performance webassembly" as of March, 2018. However, it does not work in any of the up-to-date browsers that I tested (Chrome 65, Firefox 59, Safari iOS 11.2.6). It also doesn't at any point signal to the user that the test has given up (only "running...")
Maybe an update to add an alert to the top of the page to not use this test is in order?
@blixt we should update the docs to mention that, yeah. But which page do you mean? One of the massive pages (which?) or the asm_v_wasm one from the last few comments?
@kripken Sorry, the only link that I can find via Google appears to be http://kripken.github.io/Massive/beta/
Here's the queries I tried on Google:
webassembly performance
(no. 4)webassembly benchmark
(no. 2)webassembly speed
(no. 3)wasm performance
(no. 3)wasm benchmark
(no. 2)wasm speed
(no. 2)Ah thanks @blixt , yeah, we have that "beta" page up. I think I'll just remove it, until we figure out a proper benchmarking method.
Browser: Chrome Version: 57.0.2987.110 (64-bit)
Computer: MacBook Pro (Retina, 15-inch, Mid 2015) Processor: 2.5 GHz Intel Core i7 Memory: 16 GB 1600 MHz DDR3 Graphics: Intel Iris Pro 1536 MB
OS: OSX/macOS Version: Sierra 10.12.3 (16D32)
Trace (DevTools console):
As you can see in the above trace, MASSIVE isn't detecting WebAssembly support despite the fact that when I go to http://webassembly.org/demo/, it runs as expected without any note about missing WebAssembly support.