On Sun, Jan 8, 2017 at 10:03 PM, Charles Vaughn <[email protected]> wrote:
> > > On Saturday, January 7, 2017 at 2:04:13 PM UTC-8, Brendan Bohannon wrote: >> >> I have recently been using Emscripten for building some personal projects >> as a test, but have noted some various issues. >> version = 1.35.0 >> > > You mention testing WASM. 1.35.0 doesn't support that. In any case try > using the latest 1.37.x. > > >> >> slow compilation times: >> * compiling takes a fairly long time if compared with native compilers, >> such as MSVC or GCC. >> * ex: when compiling a 200 kLOC program, compilation takes a decent >> number of minutes. >> ** program is most a basic Minecraft-style 3D engine (voxel-based). >> ** it isn't that big, and MSVC (VS2015) compiles it in under a minute. >> * can note: optimized JS output is about 8MB, vs ~ 60MB without >> optimizations. >> >> general requests: maybe try to make compile times faster? >> >> > Compilation, especially to size optimized JS will take longer than > generating an optimized .exe due to needing to optimize textual javascript. > Yes, most of current compile times are due to optimizing asm.js. We do it in parallel, so more cores help, but it's still substantial with the typical # of cores. The reason we spend that time during link time is because we compile all bitcode to JS at once. In theory we could do separate compilation, like native platforms do, and then linking is fast. However, that prevents some optimizations and in particular some crucial code size reduction optimizations, and code size really matters on the web, so the default has been to compile all bitcode to JS at once. However, some are experimenting with separate compilation now for wasm, so that will likely become an option at some point. Speaking of wasm, it already provides faster compile times, and will improve further before wasm launches (e.g. right now we emit the wasm text, which can huge, and is not needed 99% of the time - that will be fixed). The reasons for the speedup there are that the wasm optimizer in binaryen is much more efficient than the asm.js optimizer in emscripten. Regarding the LLVM wasm backend (mentioned later below) it won't improve compile times by itself (in fact it is slower because it uses LLVM's slower and single-threaded codegen and optimization). But it may bring other benefits, hopefully. > I suspect most compilation time improvements will be focused on the native > LLVM WASM backend, but I htink that's still WIP. You can try seeing if Side > Modules ( https://github.com/kripken/emscripten/wiki/Linking# > overview-of-dynamic-linking ) allow you to compile frequently modified > code in a smaller JS subset. > > >> misc: >> * compiler seems to be imposing some C++ rules onto C for some reason. >> > > Certain features of Emscripten require the use of a C++ compiler (embind > for example) > > >> * this can be addressed, but it was annoying needing to go over and stick >> in extra type-casts on pointers and similar. >> >> also more/better debugging facilities would be nice, even if only >> something like making "emrun" able to provide a GDB style interface. >> >> > You can can give CyberDWARF a shot for better printing support, but it's > still rough: https://kripken.github.io/emscripten-site/docs/ > debugging/CyberDWARF.html > > Expect WASM to deliver better debugging. In general I'd recommend having a > project that can be built either for JS or Native and primarily debugging > native. > > >> >> have observed that rendering and input-handling seem faster on Chrome, >> whereas primarily CPU-based tasks seem faster on Firefox (but offset by it >> being noticeably slower to respond to keys being pressed/released than in >> Chrome). general start-up times are a lot faster in Chrome. >> >> however, I keep getting "browser ran out of memory" type error messages >> (primarily in Chrome, which basically says something like "Aw, Snap! >> Browser ran out of memory while trying to display website.") after a period >> of time (~ 15-20 minutes), this being seemingly uneffected by the choice of >> a 256MB or 512MB heap size (note: 256MB is about the minimum I can get away >> with, with a 64-meter draw distance; in native land for a 256 meter >> draw-distance memory use is generally around 1 GB, ...). >> >> > You can get an overview of where else in your JS app you're consuming > memory with a tool like Chrome's heap profiler: https://developer. > chrome.com/devtools/docs/heap-profiling > > Firefox has a similar tool. Javascript has a maximum heap size of 1GB, so > you'll have to stay under that for your JS allocated memory. WASM memory > regions don't count against that (or at least can go beyond it). > > >> >> thoughts/comments?... >> >> >> for anyone curious, I have a built version online from here: >> https://cr88192.github.io/bgbtech_html/ >> >> I haven't pushed the changes for all this back up to GitHub yet, but >> general source for the engine is here: >> https://github.com/cr88192/bgbtech_engine2 >> >> -- > 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.
