Ah, are you saying that you would expect -Oz to produce smaller JS than -O3? That's a good point. Right now we have -Oz as equal to -O2, plus some size reducing stuff (I think none of which matters at link time). But -O3 adds better regalloc, which does reduce code size. So perhaps during link we should have -Os and -Oz also apply the better regalloc?
- Alon On Thu, Feb 26, 2015 at 8:38 AM, Boris Gjenero <boris.gjen...@gmail.com> wrote: > I tried building several different programs with memory growth enabled and > disabled, and there were no surprises. The biggest increase was 0.57% with > Acidwarp, which is small. Big stuff is increased by around 0.15%. > > There was another surprise however. Smallest code size is produced by > compiling to bytecode with -Oz and doing the final link with -O3. Typically > this should be possible if you put -Oz in CFLAGS/CXXFLAGS and -O3 in > LDFLAGS, because LDFLAGS come later in the command line and will override > the -Oz. Using -Oz for the final link produces larger JS than -O3. With > --closure 1, JS is even smaller, but that breaks stuff. > > On 2015-02-25 11:01 PM, Bailey Hayes wrote: > >> The size problem is a red herring. The utility script we run at the end >> of the build to remove duplicate functions was not running. Now the >> difference is between 19096282 and 18995209 (.1MB) which is within the >> range of expected output. >> >> On Wednesday, February 25, 2015 at 2:40:52 PM UTC-5, Alon Zakai wrote: >> >> I wonder if closure somehow interacts here (it's the only flag that >> pops out)? But I did some local tests on some projects and I don't >> see anything odd. So I don't really have any good guesses as to why >> code size increases so much on your project with memory growth. >> Strange. >> >> We could look into this more by comparing some individual functions >> with and without memory growth, but if code size is not a concern >> for you, I don't want to waste your time. >> >> - Alon >> >> >> On Tue, Feb 24, 2015 at 8:43 PM, Bailey Hayes <beha...@gmail.com >> <javascript:>> wrote: >> >> Thanks for tips! I'll try capturing differences in the CPU >> profiler while we're doing CPU intensive work and see if the >> difference is livable. I captured fps while performing >> interactions which is after most of our intensive CPU work. I am >> logging the time it takes to do most of our work and the >> differences between runs can been chalked up to network latency. >> >> I'm on the latest incoming and the only difference is >> ALLOW_MEMORY_GROWTH=0|1. Here are the rest of the relevant >> compiler args in case it helps: >> >> | >> -Oz-s FULL_ES2=1-s TOTAL_MEMORY=104857600--closure 1-s >> ALLOW_MEMORY_GROWTH=1--memory-init-file 1--emit-symbol-map >> -std=c++11-DUSE_CXX11 -DNDEBUG >> >> >> | >> >> On Tuesday, February 24, 2015 at 7:07:35 PM UTC-5, Alon Zakai >> wrote: >> >> Btw, a perhaps easier way to test this issue in chrome is to >> remove the "use asm" string from the build (without a >> recompile). The problem happens when chrome detects "use >> asm", which makes it run in turbofan, but turbofan isn't >> good at memory-growth-type code yet. So just removing/adding >> that string can change between turbofan which has the >> problem, and normal behavior which doesn't. >> >> It's also possible to tell emscripten to not emit "use asm", >> if you build with -s ASM_JS=2. That can decide if turbofan >> runs or does not run (independently of memory growth). So it >> could be a temporary workaround for this chrome issue (but >> the bug is assigned, so I'm hoping it won't be a problem for >> long). >> >> - Alon >> >> >> On Tue, Feb 24, 2015 at 3:59 PM, Alon Zakai >> <alon...@gmail.com> wrote: >> >> Yes, on that setup, the problem should happen (very new >> chrome, emscripten incoming, memory growth on). Since it >> doesn't, maybe the application is not CPU bound, but GL >> bound? If that's the case, then some amount of CPU >> slowdown on chrome might not be noticeable, since chrome >> is usually pretty good about running GL in parallel to >> the CPU. As Boris said, DOSBox is probably the extreme >> of a completely CPU-bound program, so it's the >> worst-case for this issue. >> >> I'm curious, does just enabling memory growth increase >> code size to 21MB from 18MB? Or are there other >> differences between the builds? I'm a little surprised >> to see such a large change, I saw just 1% or so on my >> tests. Might be something we need to fix in emscripten. >> >> Jukka is working to fix up the test bots, they've been >> broken for a while I'm afraid. Once that happens, we can >> tag incoming and merge to master. That might happen this >> week, but if it doesn't, then it probably won't happen >> next week because of GDC. >> >> - Alon >> >> >> On Tue, Feb 24, 2015 at 2:07 PM, Bailey Hayes >> <beha...@gmail.com> wrote: >> >> I'm still seeing 50-60fps with Chrome Canary 64-bit >> (43.0.2314.0) on OSX. I'm using options -Oz and >> ALLOW_MEMORY_GROWTH=1. The js artifact is 21MB (up >> from 18MB). I also tried Chromium on OpenSUSE. After >> reading the discussion in 3907 >> <https://code.google.com/p/v8/issues/detail?id=3907>, >> I >> would expect to see the same problems as Doom in >> Em-DOSBox. Is there something in that scenario that >> I'm missing? We have a large project that >> extensively uses OpenGL emulation (FULL_ES2=1) and >> multiple WebGL contexts. >> >> On that note, I really wanted to release using >> memory growth as we can't predict how much data a >> client will need. Right now we set memory to 100MB >> and that covers most cases. Will incoming get a tag >> soon? >> > > -- > 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 emscripten-discuss+unsubscr...@googlegroups.com. > 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
