On 1/9/2017 5:08 PM, Alon Zakai wrote:
On Sun, Jan 8, 2017 at 10:03 PM, Charles Vaughn <[email protected]
<mailto:[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.
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.
