Great, i'll be moving to incoming fairly soon to try things out on the cutting edge.
I've found some oddities that i'm unsure whether these are bugs, my misunderstanding functionality/features or otherwise. 1. -s LINKABLE=1 increases my code size by 30%! Should be a warning about that for larger projects ;) However it was also a source of "too many variables" problems in Firefox. 2. The dreaded "warning: unresolved symbols: emscripten_gl<Legacy GL function>" were resolved when I added -s LINKABLE=1, but now are back (doesn't seem to affect code execution though). 3. -s NO_EXIT_RUNTIME produced a LLVM TRAP! I didn't chase down the stack trace since it was a release mode but I should mention that I never intended on running "main" so it might not be an issue? 4. --memory-init-file 1 did cut down code and produced a ~2MB memory file, however it also caused a LLVM TRAP. 5. -s OUTLINING_LIMIT=x doesn't seem to change the code at all, no matter what number I put in the md5 is the exact same. No file size changes, no behavior changes, nothing.. is there a typo?.. Am I crazy?.. 6. --llvm-lto 1 was quite helpful, reduced 27MB to 25MB, --llvm-lto brought it 25MB to 22MB!! In my VERY limited unit tests (~25) nothing has changed, execution speed increased 3% as well, within a margin of error but it seems "stablish". Since I have both a Debug and Release version I'm thinking about blowing out the unit tests and leaving it at --llvm-lto 3, since it came in at an all star 19MB!!! And a 6.8% increase in render speed! Oddly enough, and i'm not joking, rendering loops are now neck to neck with native C++ render loop performance. Is --lvm-lto 3 to unsafe to use?.. Why? its a beautiful beacon of bountiful performance. 7. Allowing "Memory to grow" always threw an LLVM trap, is the -s TOTAL_MEMORY=X a cap on the memory use, or is this amount of memory effectively grabbed for the heap when it initializes?.. I was never clear on it and don't understand its impact to performance/init 8. -s INLINING_LIMIT=1 increased my code size by 5% and didn't really help anything that I could tell.. 9. I still get ASM validation errors: asm.js type error: incompatible number of arguments (4 here vs. 3 before). Not sure if these are related to what you fixed earlier, but the last part (1 here vs. 0 before) has now changed to (4 here vs. 3 before), I haven't updated emcc so it must be related to some of the compiler options I enabled/disabled. I can send over all the byte code and some test scripts if they're helpful. - Trevor On Monday, March 31, 2014 6:57:21 PM UTC-6, Alon Zakai wrote: > > 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]<javascript:> > > 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]<javascript:> >> > 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]<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 [email protected]. For more options, visit https://groups.google.com/d/optout.
