Thanks for the bitcode files, taking a look now. -Oz does not disable inlining necessarily, but LLVM will attempt to reduce code size at almost all costs, so generally it will not inline, but it might in some cases.
I wouldn't expect a binary file to be an issue - most websites already serve images with every page, etc. and with things like WebGL and so forth even more binary data is commonplace. - Alon On Mon, Mar 31, 2014 at 1:47 PM, Trevor Linton <[email protected]>wrote: > 1. I'll see if I can put together a straight forward test case. I believe > I might be able to patch this and see if I can submit a push. > 2. I agree, i'm unsure what exactly is happened although I did notice from > a few tests a huge spike in the garbage collection time then back to idle. > It could also be how i'm using emscripten/main loop. This never happened > when i used the emscripten_set_main_loop and simply had emscripten fire up > main. The current implementation has no main loop and acts like a shared > library. One shot timers are used to keep animation/rendering going > (webkit's Timer class is just now a wrapper around (essentially) > setTimeout/setInterval.. > 3. Yes, 1.13.0, you can find the produced byte codes here: > http://www.trueinteractions.com/bundle.tar.gz (note these are all pulled > together for the final .js with a handle full of files) > 4. I'm at the latest, here's what is produced with emsdk list after an > update: > > The following individual tools exist: > > clang-3.2-64bit INSTALLED > > clang-3.3-64bit INSTALLED > > * clang-e1.13.0-64bit INSTALLED > > * node-0.10.18-64bit INSTALLED > > emscripten-1.5.6 > > emscripten-1.7.1 > > emscripten-1.7.8 > > emscripten-1.8.2 INSTALLED > > emscripten-1.9.5 > > emscripten-1.10.4 > > emscripten-1.12.0 INSTALLED > > * emscripten-1.13.0 INSTALLED > > emscripten-incoming > > emscripten-master > > The following Emscripten SDK versions are available: > > sdk-incoming-64bit > > sdk-master-64bit > > sdk-1.5.6-64bit > > sdk-1.7.1-64bit > > sdk-1.7.8-64bit > > sdk-1.8.2-64bit INSTALLED > > sdk-1.9.5-64bit > > sdk-1.10.4-64bit > > sdk-1.12.0-64bit INSTALLED > > * sdk-1.13.0-64bit INSTALLED > > 5. Essentially when you use --proxy-to-worker the canvas object that > SDL_UpperBlit needs isn't available and/or not being proxied from what I > could tell. > 6. Yeah, i'm hesitant to use a memory initialized file since its tricky in > certain contexts to ensure the file is properly included (as most users are > completely unaware of the file type and may assume its a debug file), > second reason is i'm unwary how some servers may look at shipping the > binary file / how it may be loaded. I've had tricky problems getting > binary data out of XmlHttpRequest objects due to some less than stellar > CDN/http servers out there. But I agree, its a perfect option and works for > 95% of my use cases. > > 7. It would be nice to not need the closure compiler; it does take about a > half an hour to finish on my machine :/ > > 8. It's 4.1 MB gzipped, about 3.5 with xz. I do wish there were more > sophisticated transport/loading/memory allocation techniques in JavaScript > :/. > > 9. None, does the -Oz option effectively disable outlining? I suppose its > not a huge problem, I just assumed outlining had no dependency/disabling > options. > > 10. I'll look into these optimizations, thanks! > > On Monday, March 31, 2014 11:48:00 AM UTC-6, Alon Zakai wrote: > >> Wow, nice! :) >> >> Notes on the issues you mentioned: >> >> 1. Not sure I follow that, can you please file a bug with a small >> testcase? >> 2. Very odd about chrome being so slow here. Profiler shows "idle" so it >> might be parsing or something else that is not actually JS execution. It's >> a good idea to file a bug on v8 so they can take a look at it. >> 3. Are you using latest emscripten? If so can you send me the final >> bitcode file (--save-bc, or one of the EMCC_DEBUG output files) and command >> you use to build, and I'll debug that locally? >> 4. Those should be removed on latest incoming, do you still see them >> there? (which version of emscripten are you on? use emcc -v to verify setup >> is ok) >> 5. I think I saw an issue filed earlier on a similar thing, was that >> this? If not, please file one with a testcase. >> 6. There is https://github.com/kripken/emscripten/issues/2188 but the >> far more optimal solution is to use a binary init file, >> --memory-init-file 1 which will save a lot of space. >> 7. I've seen closure in the past have similar issues. Can file a bug if >> you want, they tend to fix stuff like that quickly. But, with 6 and 8, i >> don't think closure will be needed, i don't use it anymore. >> 8. Native browser gzip support should be good enough - how big is the >> file with a mem init file and after gzip? >> 9. Does outlining not affect code size at all? Perhaps it is not being >> activated for some reason - does it work on smaller testcases for you? How >> are you using it? It should not be needed though, if you build sources with >> -Oz. >> 10. Notes on build flags: >> >> --llvm-opts 3 should not make any difference if -O2 or -O3 is >> already set >> As mentioned above, I would add --memory-init-file 1 >> -s NO_EXIT_RUNTIME=1 can reduce code size. see settings.js for >> meaning >> --llvm-lto 1 is worth trying. It can be good or bad for code size >> --llvm-lto 1 -s INLINING_LIMIT=1 is LTO but without outlining, also >> worth trying >> >> - Alon >> >> >> >> >> On Mon, Mar 31, 2014 at 9:08 AM, Trevor Linton <[email protected]>wrote: >> >>> Hi All, >>> >>> For the past few months i've been porting webkit to JavaScript using >>> emscripten. >>> >>> You can find a working demo (Firefox only) here: http://trevorlinton. >>> github.io/webkit.js/demo.html >>> You can find the project sources (compile settings are in common.gypi) >>> here: http://github.com/trevorlinton/webkit.js >>> >>> I have a few issues with Emscripten I haven't been able to work around: >>> >>> 1. It seems SDL with cairo inverts the red and green channels, this >>> from what I can see in the library code doesn't correctly handle RGBA >>> masks >>> passed in to SDL_CreateRGBSurface. >>> 2. Chrome/Safari freeze for 30-90 seconds to what I can only >>> determine is garbage collection. >>> 3. Firefox fails to validate the ASM, I assume this is due to a >>> globally initialized variable but can't seem to track down where.. >>> 4. Emscripten warns of undefined symbols to >>> 'emscripten_gl<legacyfunction>' even though no GL code exists.. >>> 5. Using SDL as a worker fails since it still tries to use a native >>> canvas object in a Worker, rather than proxying it up to the host page. I >>> had to create some very harsh shims to make this work. >>> 6. Is there anyway memory can be initialized with a Uint32 rather >>> than Uint8? I'm my tests this would cut down my code size of webkit.js >>> from >>> 19MB to 15MB!!! >>> 7. Closure compilers ran on it actually produce INVALID javascript, >>> I get a syntax error of '--/a' which is nonsensical and fairly >>> surprising. >>> 8. There's no seemingly easy way to compress/inflate/deflate code >>> using XZ, this would be hugely helpful as it cuts the JS code down to >>> 3.5MB! I realize this will happen on a server level but would be VERY >>> helpful. >>> 9. Outlining my code does absolutely nothing, no matter what value I >>> set in the compiler. Any ideas why this would be? >>> 10. If you review common.gypi on the project to see the >>> debug/release compiler settings is there anything I can do to increase >>> the >>> speed/code size? >>> >>> For reference i'm using 1.13.0 on MacOSX. >>> >>> -- >>> 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. > -- 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.
