> On Sep 16, 2018, at 2:09 AM, 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.
I think that you want a parent bug that’s just an umbrella and then have bugs that block it for each patch. -Filip > > 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 > > 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, an experimental port of node.js to the JavaScriptCore >>>> engine and iOS specifically. >>>> >>>> node-jsc's core component, "jscshim" (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 with a custom toolchain >>>> file. >>>> >> I'm really happy to hear that your node-jsc is using JSCOnly ports :) >>>> The project also includes 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. 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" describes WebKit's usage in node-jsc and the >>>> major changes\additions I've made in my fork (node-jsc's README and >>>> jschim's documentation 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
