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? >>>>> >>>>> On Friday, February 20, 2015 at 1:18:59 AM UTC-5, Alon Zakai wrote: >>>>>> >>>>>> Based on discussion in that bug, I disabled memory growth by default >>>>>> for now. >>>>>> >>>>>> - Alon >>>>>> >>>>>> >>>>>> On Thu, Feb 19, 2015 at 9:23 PM, Alon Zakai <alon...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hmm, on the growth build, it halts on "Emulation aborted due to >>>>>>> nested emulation timeout." for me on chrome 41, but works on firefox. >>>>>>> >>>>>>> - Alon >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 19, 2015 at 9:11 PM, Boris Gjenero <boris....@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Okay, I have created: https://code.google.com/p/v8/i >>>>>>>> ssues/detail?id=3907 >>>>>>>> >>>>>>>> Builds are linked there. I'm providing the same links here also for >>>>>>>> convenience: >>>>>>>> >>>>>>>> Growth: https://dl.dropboxusercontent.com/u/16662598/Ports/DOSBox- >>>>>>>> web/doom.html?engine=dosbox-growth.js >>>>>>>> >>>>>>>> No growth: https://dl.dropboxusercontent. >>>>>>>> com/u/16662598/Ports/DOSBox-web/doom.html?engine=dosbox-nogrowth.js >>>>>>>> >>>>>>>> On 2015-02-19 11:15 PM, Alon Zakai wrote: >>>>>>>> >>>>>>>>> This is very surprising and a serious issue that we should report >>>>>>>>> to v8. >>>>>>>>> I would create --profiling builds with and without that option, >>>>>>>>> and file >>>>>>>>> a bug with those links. >>>>>>>>> >>>>>>>>> The reason it is surprising is that memory growth affects code in >>>>>>>>> a very >>>>>>>>> small way. It uses a few more local variables, but that's it. I >>>>>>>>> suppose >>>>>>>>> it might tip it over some internal limit in TurboFan or something >>>>>>>>> like that. >>>>>>>>> >>>>>>>>> - Alon >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 19, 2015 at 2:52 PM, Boris Gjenero < >>>>>>>>> boris....@gmail.com >>>>>>>>> <mailto:boris....@gmail.com>> wrote: >>>>>>>>> >>>>>>>>> When running Doom in Em-DOSBox, allowing memory growth results >>>>>>>>> in a >>>>>>>>> MASSIVE performance penalty in Chrome 42.0.2305.3 dev (64-bit). >>>>>>>>> >>>>>>>>> With -s ALLOW_MEMORY_GROWTH=0 Em-DOSBox runs Doom a lot faster >>>>>>>>> in >>>>>>>>> Chrome 42 compared to Chrome 40. Chrome 42 speed is similar to >>>>>>>>> Firefox. Without that option, Chrome 42 is much slower than >>>>>>>>> Chrome 40. >>>>>>>>> >>>>>>>>> I assume this has something to do with the new TurboFan >>>>>>>>> optimizing >>>>>>>>> compiler in the dev branch. Maybe it can't be used with memory >>>>>>>>> growth enabled or that disables some optimizations. I realize >>>>>>>>> this >>>>>>>>> is the dev branch of Chrome and this issue may be fixed before >>>>>>>>> it is >>>>>>>>> released. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>> >>>> >>>> >>> -- >> 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 <javascript:>. >> 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.
