optimizer.exe is run from multiple workers in a chunked fashion. I would recommend you build emscripten from scratch so you can take advantage of the latest version.
I would also recommend Ninja over make, but you'll need to switch to a CMake project, though that has the benefit of being able to generate both ninja projects and Visual Studio ones from the same source. On Monday, January 9, 2017 at 6:58:41 PM UTC-8, Brendan Bohannon wrote: > > On 1/9/2017 5:08 PM, Alon Zakai wrote: > > > > On Sun, Jan 8, 2017 at 10:03 PM, Charles Vaughn <[email protected] > <javascript:>> 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. > > > I am not sure if this is threaded, as it looks like during build, lots of > time is spent in "optimizer.exe", which is at ~ 12% CPU load. this is more > typically the speed seen from a single-threaded program on this system. > > looking at the tool code though, I am not seeing any evidence of > multi-threading, it could be I need a newer version, as this one has > time-stamps in 2015?... > > > checking: I am guessing 1.35.0 is using a very early version of WASM. > may try seeing if I can go over to a newer one... > > > 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. > > > hopefully it gets faster. > > > 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. > > > ok. > > > I have noted that curiously, "--preload-file" seems to have an effect on > time spent with "make" with no "-j" option, but seemingly only minimal > effect with "make -j 4" enabled. > > noted "make -j 6" and "make -j 8" seem to take a similar amount of time to > "make -j 4", though "make -j 4" does contribute a noteworthy speedup vs > plain "make". > > I am guessing "make -j" is taking the time of the longest item, whereas > plain make is cumulative, and the cost of "preload" scales with the number > of things built (currently side-apps are built with copies of the preloaded > data), whereas with "make -j" it only contributes to the time of the > longest task?... > > > -- 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.
