Ah, oops, the native optimizer wasn't working on minified output (default in -O2+). Fixed now on incoming. Might need to emcc --clear-cache to rebuild the optimizer, currently.
- Alon On Fri, Nov 14, 2014 at 4:00 PM, Floh <[email protected]> wrote: > Strange, I can't seem to get it to use the native optimizers, at least I'm > not seeing any 'building native optimizer' or 'js optimizer using native' > messages. I'm using the emscripten-sdk with incoming, and I'm seeing the > EMCC_NATIVE_OPTIMIZER in tools/js_optimizer.py, what am I doing wrong? :) > > Here's the complete console dump: > > FlohOfWoe:oryol floh$ EMCC_NATIVE_OPTIMIZER=1 > sdks/osx/emsdk_portable/emscripten/incoming/emcc -O2 hello.c > DEBUG root: PYTHON not defined in ~/.emscripten, using > "/usr/bin/python2" > DEBUG root: JAVA not defined in ~/.emscripten, using "java" > WARNING root: invocation: > sdks/osx/emsdk_portable/emscripten/incoming/emcc -O2 hello.c (in > /Users/floh/projects/oryol) > INFO root: (Emscripten: Running sanity checks) > DEBUG root: compiling to bitcode > DEBUG root: emcc step "parse arguments and setup" took 0.00 seconds > DEBUG root: compiling source file: hello.c > DEBUG root: running: > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/clang/fastcomp/build_incoming_64/bin/clang > -target asmjs-unknown-emscripten -D__EMSCRIPTEN_major__=1 > -D__EMSCRIPTEN_minor__=26 -D__EMSCRIPTEN_tiny__=1 > -Werror=implicit-function-declaration -nostdinc -Xclang -nobuiltininc > -Xclang -nostdsysteminc -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/local/include > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/compat > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/emscripten > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/libc > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/lib/libc/musl/arch/js > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/libcxx > -O2 -mllvm -disable-llvm-optzns -emit-llvm -c hello.c -o > /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0.o > -Xclang > -isystem/Users/floh/projects/oryol/sdks/osx/emsdk_portable/emscripten/incoming/system/include/SDL > DEBUG root: emcc step "bitcodeize inputs" took 0.01 seconds > DEBUG root: optimizing hello.c > DEBUG root: emcc: LLVM opts: -O3 > DEBUG root: emcc step "process inputs" took 0.29 seconds > DEBUG root: will generate JavaScript > DEBUG root: including libc > DEBUG root: emcc step "calculate system libraries" took 0.01 seconds > DEBUG root: linking: > ['/var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0_1.o', > '/Users/floh/.emscripten_cache/libc.bc'] > DEBUG root: emcc: llvm-linking: > ['/var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/hello_0_1.o', > '/Users/floh/.emscripten_cache/libc.bc'] to > /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/a.out.bc > DEBUG root: emcc step "link" took 0.02 seconds > DEBUG root: saving intermediate processing steps to > /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/emscripten_temp > DEBUG root: emcc: LLVM opts: -strip-debug -internalize > -internalize-public-api-list=main,malloc,free -globaldce > -pnacl-abi-simplify-preopt -pnacl-abi-simplify-postopt > DEBUG root: emcc step "post-link" took 0.02 seconds > DEBUG root: LLVM => JS > DEBUG root: PYTHON not defined in ~/.emscripten, using > "/usr/bin/python2" > DEBUG root: JAVA not defined in ~/.emscripten, using "java" > DEBUG root: not building relooper to js, using it in c++ backend > DEBUG root: emscript: llvm backend: > /Users/floh/projects/oryol/sdks/osx/emsdk_portable/clang/fastcomp/build_incoming_64/bin/llc > /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/tmp9Plu1v/a.out.bc > -march=js -filetype=asm -o > /var/folders/t5/y4k268cs1fl4hsygfbrtjzl00000gn/T/emscripten_temp/tmpKKukJK.4.js > -O2 -emscripten-max-setjmps=20 > DEBUG root: emscript: llvm backend took 0.0165209770203 seconds > DEBUG root: emscript: js compiler glue > DEBUG root: emscript: glue took 0.216127157211 seconds > DEBUG root: asm text sizes[[105107, 1849, 25], 0, 130, 1180, 0, 0, 29, > 274, 234, 663, 348] > DEBUG root: emscript: final python processing took 0.00248885154724 > seconds > DEBUG root: emcc step "emscript (llvm=>js)" took 0.40 seconds > DEBUG root: wrote memory initialization to a.out.js.mem > DEBUG root: emcc step "source transforms" took 0.01 seconds > DEBUG root: running js post-opts > DEBUG root: applying js optimization passes: ['asm', 'emitJSON', > 'minifyWhitespace'] > chunkification: num funcs: 7 actual num chunks: 1 chunk size range: 108251 > - 108251 > . > DEBUG root: applying js optimization passes: ['asm', 'receiveJSON', > 'eliminate', 'simplifyExpressions', 'simplifyIfs', 'registerize', > 'minifyNames', 'emitJSON', 'minifyWhitespace'] > chunkification: num funcs: 3 actual num chunks: 1 chunk size range: 307159 > - 307159 > . > DEBUG root: applying js optimization passes: ['asm', 'receiveJSON', > 'cleanup', 'asmLastOpts', 'last', 'minifyWhitespace'] > chunkification: num funcs: 3 actual num chunks: 1 chunk size range: 162909 > - 162909 > . > running cleanup on shell code > DEBUG root: emcc step "js opts" took 0.96 seconds > DEBUG root: emcc step "final emitting" took 0.00 seconds > DEBUG root: total time: 1.72 seconds > > > > Am Freitag, 14. November 2014 02:19:47 UTC+1 schrieb Alon Zakai: > >> Early this year the fastcomp project replaced the core compiler, which >> was written in JS, with an LLVM backend in C++, and that brought large >> compilation speedups. However, the late JS optimization passes were still >> run in JS, which meant optimized builds could be slow (in unoptimized >> builds, we don't run those JS optimizations, typically). Especially in very >> large projects, this could be annoying. >> >> Progress towards speeding up those JS optimization passes just landed, >> turned off, on incoming. This is not yet stable or ready, so it is *not* >> enabled by default. Feel free to test it though and report bugs. To use it, >> build with >> >> EMCC_NATIVE_OPTIMIZER=1 >> >> in the environment, e.g. >> >> EMCC_NATIVE_OPTIMIZER=1 emcc -O2 tests/hello_world.c >> >> It just matters when building to JS (not building C++ to object/bitcode). >> When EMCC_DEBUG=1 is used, you should see it mention it uses the native >> optimizer. The first time you use it, it will also say it is compiling it, >> which can take several seconds. >> >> The native optimizer is basically a port of the JS optimizer passes from >> JS into c++11. c++11 features like lambdas made this much easier than it >> would have been otherwise, as the JS code has lots of lambdas. The ported >> code uses the same JSON-based AST, implemented in C++. >> >> Using c++11 is a little risky. We build the code natively, using clang >> from fastcomp, but we do use the system C++ standard libraries. In >> principle if those are not c++11-friendly, problems could happen. It seems >> to work fine where I tested so far. >> >> Not all passes have been converted, but the main time-consuming passes in >> -O2 have been (eliminator, simplifyExpresions, registerize). (Note that in >> -O3 the registerizeHarder pass has *not* yet been converted.) The toolchain >> can handle running some passes in JS and some passes natively, using JSON >> to serialize them. >> >> Potentially this approach can speed us up very significantly, but it >> isn't quite there yet. JSON parsing/unparsing and running the passes >> themselves can be done natively, and in tests I see that running 4x faster, >> and using about half as much memory. However, there is overhead from >> serializing JSON between native and JS, which will remain until 100% of the >> passes you use are native. Also, and more significantly, we do not have a >> parser from JS - the output of fastcomp - to the JSON AST. That means that >> we send fastcomp output into JS to be parsed, it emits JSON, and we read >> that in the native optimizer. >> >> For those reasons, the current speedup is not dramatic. I see around a >> 10% improvement, far from how much we could reach. >> >> Further speedups will happen as the final passes are converted. The >> bigger issue is to write a JS parser in C++ for this. This is not that easy >> as parsing JS is not that easy - there are some corner cases and >> ambiguities. I'm looking into existing code for this, but not sure there is >> anything we can easily use - JS engine parsers are in C++ but tend not to >> be easy to detach. If anyone has good ideas here that would be useful. >> >> - Alon >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
