Open frxstrem opened 8 years ago
The wasm benchmarks here use 0xa wasm, while browsers currently use 0xb. Emscripten and Binaryen are now somewhere between 0xb and 0xc, so we can probably update these tests to 0xc when that stabilizes (probably a few weeks). Overall, wasm is in a lot of flux now so it's hard to get everything in sync all the time.
I have a demo that is now broken under Canary, I didn't changed anything, is it because my browser downloaded an update? And how to solve it, just update emsdk once it's using 0xc?
Yes, canary has been updating the wasm version over the last week. Once emscripten has 0xc support, updating the emsdk should fix things.
Cool, do you have an estimate - roughly - about when emscripten is upgraded to 0xc? Thanks
There should be just some final binary fixes, hopefully a matter of days.
Can you help with the following error?
./emsdk update ./emsdk install sdk-incoming-64bit ...
CMake Error: The current CMakeCache.txt directory /Users/leefsmp/emsdk/clang/fastcomp/build_incoming_64/CMakeCache.txt is different than the directory /Users/leefsmp/emscripten/clang/fastcomp/build_incoming_64 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt CMake Error: The source "/Users/leefsmp/emsdk/clang/fastcomp/src/CMakeLists.txt" does not match the source "/Users/leefsmp/emscripten/clang/fastcomp/src/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. CMake invocation failed due to exception! Working directory: /Users/leefsmp/emsdk/clang/fastcomp/build_incoming_64 Command '['cmake', '-G', 'Unix Makefiles', '-DCMAKE_BUILD_TYPE=RelWithDebInfo', '-DPYTHON_EXECUTABLE=/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python', '-DLLVM_TARGETS_TO_BUILD=X86;JSBackend', '-DLLVM_INCLUDE_EXAMPLES=OFF', '-DCLANG_INCLUDE_EXAMPLES=OFF', '-DLLVM_INCLUDE_TESTS=OFF', '-DCLANG_INCLUDE_TESTS=OFF', '/Users/leefsmp/emsdk/clang/fastcomp/src']' returned non-zero exit status 1 Installation failed!
Ok I've wipeout my old SDK, updated CMake, downloaded and installed a fresh version ... now getting this when loading my wasm in canary:
failed to compile wasm module: Error: Wasm.instantiateModule(): Wasm decoding failedResult = section was longer than expected size (186 bytes expected, 187 decoded) @+201
Sadly we are not yet compatible. There are a bunch of known issues, and I'm actually not sure how many are masked by them that we don't see yet. So could be another week or two.
Is there a browser where i can run wasm right now? my code doesnt load in firefox nightly either and I've got a meetup tomorrow where I wanted to demo some stuff ... can i get a version of canary compat with my sdk? thx for quick feedback
The main wasm demo (angry bots) should work in firefox nightly and chrome canary. But toolchains and browsers aren't in sync enough to run code you compile yourself. You could in theory use an old canary or nightly (e.g. old firefoxes are here) that supports 0xb (probably a month or two ago is ok), plus binaryen on it's 0xb tag, should work.
The wasm benchmarks here use 0xa wasm, while browsers currently use 0xb.
Any plans/updates about updating these to 0xc/0xd in wasm branch? Would be nice to have a cross browser comparison for these wasm benchmarks. Also, I noticed that the Embenchen repo has 0xd wasm files for these benchmarks. I built wasm using binaryen from the asm.js files provided in this repo, to get the latest version. However, the JS file (which switch between wasm/asmjs) has some issues, as it hasn't been updated recently with newer constructs, so I couldn't run it. I'm guessing building with emscripten + binaryen from C++ source would solve all this. Any insights?
I don't plan to update massive any time soon, since the startup etc. tests need to be rethought - because wasm startup works differently (explicit caching, etc.) - and I doubt I'll have time. But if you or someone else wants to do it that's great of course.
So until we figure out startup, what is left here is throughput, and for that, as you said embenchen has 0xd binaries which test it, and it covers much of the same ground, plus some more. Not a pretty benchmark but when people ask me for something for internal testing I point them to it.
Yeah, just building the asm.js won't work out the box. Worse, it would not use all wasm opts, so it's not a good measurement. Need to build from scratch from source (driver.js has instructions), as you said.
When I'm running the benchmarks, it stops at the second benchmark (box2d-wasm-throughput) with this exception in the console:
Running in Chrome 54 beta.