Hi Koby,

This sounds awesome. A good list of people to CC on the bug for reviews are:


- Saam

> On Sep 16, 2018, at 11:44 AM, Filip Pizlo <fpi...@apple.com> wrote:
>> 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
webkit-dev mailing list

Reply via email to