It's expected that firefox start at its maximal speed, it does AOT compilation of asm.js code, so it avoids all the JIT analysis/warmup stuff that slows v8 down for the first 10 iterations or so.
- Alon On Mon, Jun 23, 2014 at 7:32 PM, Trevor Linton <[email protected]> wrote: > I'm checking into it, there is something strange, Chrome's V8 ends up > converging around 0.17 seconds after 12/15 iterations, 0.085 native (exact > same code compiled into C++ with a opengl shim) is not shabby at all. But > i'm still flabbergasted as to why Firefox hits down into the 0.09 area, i'm > probably going to have to chalk this up to some sort of latency in > implementations as the difference in time is getting a bit too low to > accurately compare apples-to-apples between implementations (even if one > callback had a 0.05 latency that could be huge in the timing. > > At any rate, if you find any other ways to make it faster (or smaller) > please let me know! With that optimization jump its now pretty damn on-par > with current-gen renderers performance for 99% of most users use cases. > > > On Monday, June 23, 2014 8:12:38 PM UTC-6, Alon Zakai wrote: > >> Heh, I'd expect it to be competitive with native, not better ;) My guess >> is a measurement artifact, like something in the browser is async and >> returns immediately, and is executed later after the benchmark already >> reports the result. Or, perhaps hardware accelerated rendering is not used >> in the native build for some reason, or something like that? >> >> - Alon >> >> >> >> On Mon, Jun 23, 2014 at 5:39 PM, Trevor Linton <[email protected]> >> wrote: >> >>> *Alon --* >>> >>> Thanks so much for the hint! I totally blanked making sure the ASM_JS >>> was set back to 1 from 0, this had a huge improvement in performance. >>> Chrome's render speed dropped in half from 2.3 second for complex >>> SVG/text/cairo/freeytpe tests with gradients to 1.1 seconds. >>> >>> But Firefox, holy crap... it went from 2.6 seconds to 0.098 >>> seconds... (no joke, i dumped all of my cache and restarted then changed >>> the file name path because I thought it was a caching issue). I need to >>> stop and put this in perspective... Exact same rendering test in native C++ >>> code takes 0.83 seconds (100 run average)..... I'm a bit confused if >>> there's still some sort of trickery going on as there's no way it could >>> possibly be an order of magnitude faster... >>> >>> Here's the final link command: /Users/tlinton/ >>> Library/Emscripten/emscripten/1.16.0/emcc -s >>> EXPORTED_FUNCTIONS="['_main','_scalefactor','_createWebKit', >>> '_setHtml','_setTransparent','_scrollBy','_resize']" --embed-files >>> ../src/assets/fontconfig/fonts@/usr/share/fonts --embed-files >>> ../src/assets/fontconfig/config/fonts.conf@/etc/fonts/fonts.conf >>> --embed-files ../src/assets/fontconfig/cache@/usr/local/var/cache/fontconfig >>> -s FULL_ES2=1 -o webkit.html -s ASM_JS=1 -s OUTLINING_LIMIT=100000 -s >>> TOTAL_MEMORY=100663296 -O3 --llvm-opts 3 --llvm-lto 3 -g0 >>> obj/src/webkit.WebView.o obj/src/webkit.Main.o libxml.bc libjpeg_turbo.bc >>> libpng.bc libfreetype.bc libharfbuzz.bc libcairo.bc libzlib.bc libpixman.bc >>> libfontconfig.bc libwebcore_xml.bc libwebcore_wtf.bc libwebcore_svg.bc >>> libwebcore_loader.bc libwebcore_html.bc libwebcore_dom.bc libwebcore_css.bc >>> libwebcore_rendering.bc libwebcore_page.bc libwebcore_style.bc >>> libwebcore_derived.bc libwebcore_platform.bc libwebcore_history.bc >>> libwebcore_editing.bc libwebcore_angle.bc libwebcore_support.bc >>> >>> You can find the source at http://trevorlinton.github.io/webkit.bin.js >>> (and subsequently the demo at http://trevorlinton.github.io. >>> >>> *Sergey--* >>> >>> Certainly there's a few odds and ends that need to be corrected on >>> Cairo, you can find the commits in the webkit.js folder, mostly around >>> dealing with cairo's, uhm, "eager" use of casting function signatures. In >>> addition XML parsing is fairly straight forward. In all honesty it would be >>> interesting to see a C# runtime compiled down into a javascript asm.js >>> loop. I'm unsure what additional efforts there would be beyond that but I >>> know of quite a few projects that would benefit from it (including >>> Microsoft's own). >>> >>> I wonder if like SVG, you could write its own layout document/style tree >>> for XAML, then add in IDL bindings that instead of javascript could >>> integrate more elegantly into a C# compiled down javascript reduction. I >>> only say this as you'd save yourself some headaches implementing things >>> such as resource fetching, compositing, hi-dpi support and all of the other >>> anxilary pain in the butt features. You effectively could just fork >>> webkit.js and start adding in a new style parsing tree similar to SVG then >>> change the compiler to simply not include the HTML/CSS/SVG tree. Just a >>> thought... >>> >>> - Trevor >>> >>> On Monday, June 23, 2014 12:06:45 PM UTC-6, Sergey Kurdakov wrote: >>>> >>>> Hi Trevor, >>>> >>>> this is really great example which might inspire for other similar >>>> projects. >>>> >>>> One which immediately came to me is possibility to run silverlight in >>>> browser without plugins. >>>> >>>> Moonlight code is very similar to your webkit port: it renderes xaml >>>> using cairo for all text and graphics. And you managed to have this kind >>>> of rendering to be hardware accelerated. Then it is trivial to submit a >>>> tree of xaml/xml elements from parser to render and JSIL project will >>>> provide compilation of C# to javascript - so, essentially it is possible to >>>> have a solution which will allow >>>> current silverlight projects to work without ms plugin. And due to >>>> attempts of firefox team to get rid of silverlight plugin it is very >>>> important for those who wrote a lot of code to have some even slow fallback >>>> solution. >>>> >>>> quite possibly similar approach might contribute to development of more >>>> robust javascript flash simulation in project Shumway >>>> https://github.com/mozilla/shumway >>>> >>>> so, thanks for inspirational project. I hope it will lead in few years >>>> to a situation where emscripten/javascript can replace all popular plugins >>>> like flash and silverlight in browser, and will allow to retain on the web >>>> all hard earned software even if initial vendor drops any support. >>>> >>>> Regards >>>> Sergey >>>> >>>> -- >>> 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.
