Ok, webkit ran into 2 tiny corner cases, fixed both on incoming and now it validates.
- Alon On Mon, Mar 31, 2014 at 4:30 PM, Alon Zakai <[email protected]> wrote: > 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.
