Yusuke Suzuki - That's awesome! thanks for taking the time to do this. I will merge your changes to my fork, I'm really curious on how this will affect compilation times and binary size.
Filip Pizlo, Saam Barati - Thanks! I will create the bugs and patches as soon as I can, it's just the holidays here so I haven't had enough time to work :) On Sat, Sep 22, 2018 at 8:36 AM Yusuke Suzuki <yusukesuz...@slowstart.org> wrote: > On Sun, Sep 16, 2018 at 6:09 PM Koby Boyango <koby.b@mce.systems> wrote: > >> Thanks for taking the time to look into the project :) >> >> Filip - I would love to. Should I create one bug for all of the patches, >> or a bug for each patch? >> Also, there is an existing bug that I've reported a while ago, but worked >> around it for now: https://bugs.webkit.org/show_bug.cgi?id=184232. It >> isn't relevant in newer versions of node (it came from node's Buffer >> constructor, which have changed since), but I'll still be happy to send a >> patch if needed. >> >> Yusuke - It's interesting to compare, especially on an iOS device. I will >> also try to do some measurements :) Do you have a benchmark you recommend? >> But assuming it is worth it, enabling LLInt ASM without the JIT would be >> great as it would probably reduce the binary size and compilation time by >> quite a bit. >> NativeScript is also using it without the JIT (and they link to an >> article containing some benchmarks), so they would profit from this too. >> >> https://github.com/NativeScript/ios-runtime/commit/1528ed50f85998147b190c22a390b5eca36c5acb >> > > Actually, LLInt ASM interpreter shows 15% performance win in Kraken > benchmark[1]. > Based on this fact, I've just enabled LLInt ASM interpreter when using > `ENABLE_JIT=OFF` for x64 and ARM64 environments[2]. > > [1]: > https://lists.webkit.org/pipermail/webkit-dev/2018-September/030157.html > [2]: https://trac.webkit.org/r236381 > > > >> >> >> Koby >> >> On Sat, Sep 15, 2018 at 2:51 AM Yusuke Suzuki <yusukesuz...@slowstart.org> >> wrote: >> >>> Really great! >>> >>> node-jsc sounds very exciting to me. From the users' view, t is nice if >>> we run app constructed in node.js manner in iOS devices. >>> In addition, from the JSC developers' view, it is also awesome. It >>> allows us to easily run node.js libraries / benchmarks / tests on JSC, >>> which is really great since, >>> >>> 1. We can run tests designed for node.js, it makes our JSC >>> implementation more solid. >>> 2. We can run benchmarks designed for node.js including JS libraries. JS >>> libraries distributed in npm are more and more used in both node.js and >>> browser world. >>> If we can have a way to run benchmarks in popular libraries on JSC >>> easily, that offers great opportunities to optimize JSC on them. >>> >>> On Sat, Sep 15, 2018 at 5:20 AM Filip Pizlo <fpi...@apple.com> wrote: >>> >>>> Wow! That’s pretty cool! >>>> >>>> I think that it would be great for this to be upstreamed. Can you >>>> create a bug on bugs.webkit.org and post your patches for review? >>>> >>>> -Filip >>>> >>>> On Sep 13, 2018, at 4:02 PM, Koby Boyango <koby.b@mce.systems> wrote: >>>> >>>> Hi, >>>> >>>> I'm Koby Boyango, a senior researcher and developer at mce, and I've >>>> created node-jsc <https://github.com/mceSystems/node-jsc>, an >>>> experimental port of node.js to the JavaScriptCore engine and iOS >>>> specifically. >>>> >>>> node-jsc's core component, "jscshim" (deps/jscshim) >>>> <https://github.com/mceSystems/node-jsc/tree/master/deps/jscshim>, >>>> implements (parts of) v8 API on top of JavaScriptCore. It contains a >>>> stripped down version of WebKit's source code (mainly JSC and WTF). To >>>> build WebKit, I'm using CMake to build the JSCOnly port, with JSC\WTF >>>> compiled as static libraries. For iOS I'm using my own build script >>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/build_jsc.py> >>>> with a custom toolchain file >>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/ios.toolchain.cmake>. >>>> >>>> >>>> I'm really happy to hear that your node-jsc is using JSCOnly ports :) >>> >>>> The project also includes node-native-script >>>> <https://github.com/mceSystems/node-native-script>, NativeScript's iOS >>>> runtime refactored as node-jsc native module, allowing access to native iOS >>>> APIs directly from javascript. >>>> >>>> So first of all, I wanted to share this project with the WebKit >>>> developer community. >>>> It's my first time working with WebKit, and node-jsc has been a great >>>> opportunity to experiment with it. >>>> >>>> Second, as I needed to make some minor changes\additions, I'm using my >>>> own fork <https://github.com/mceSystems/webkit>. I would love to >>>> discuss some of the changes I've made, and offer some patches if you'll >>>> find them useful. >>>> "WebKit Fork and Compilation >>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md>" >>>> describes WebKit's usage in node-jsc and the major changes\additions I've >>>> made in my fork (node-jsc's README >>>> <https://github.com/mceSystems/node-jsc/blob/master/README.md> and jschim's >>>> documentation >>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/jscshim.md> >>>> contains some more information). >>>> >>>> Great, it is really nice if you have a patch for upstream :) >>> Looking through the documents, I have one question on LLInt v.s. CLoop. >>> >>> >>> https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md#webkit-port-and-compilation >>> > Use the optimized assembly version of LLInt (JSC's interpreter), not >>> cloop. This requires enabling JIT support, although we won't be using the >>> JIT (but we can omit the FTL jit). >>> >>> I would like to know how fast LLInt ASM interpreter is when comparing >>> CLoop interpreter. >>> If it shows nice speedup, enabling LLInt ASM interpreter without JIT for >>> major architectures (x64, ARM64) sounds nice. >>> As a bonus, if we offer this build configuration (using LLInt ASM >>> interpreter without JIT), we can enable SamplingProfiler for this, which is >>> disabled for CLoop builds. >>> >>> Personally, I'm also interested in this thing. I'll set up the >>> environment to measure it later too :) >>> >>> >>>> Besides that, I will appreciate any opinions\ideas\insights\suggestions >>>> :) >>>> >>>> >>> >>> >>> >>> >>> >>>> Koby >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>> > > -- > Best regards, > Yusuke Suzuki >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev