[webkit-dev] [webkit-gtk] Porting V8 to WebKit

[Nayan Kumar K]

Sorry to open up this discussion again, :) Based on the recent developments
in bug https://bugs.webkit.org/show_bug.cgi?id=32452 and
https://bugs.webkit.org/show_bug.cgi?id=69469, it seems like some are keen
on having V8 as an configurable build option in WebKit-GTK.
One obvious advantage of using V8 in WebKit-GTK is faster JS engine (at this
point of time!). Moreover, it will be provided as separate build option and
SFX will continue to be the default JS engine. If we ever in future wish to
shift completely to V8, such transition would be smoother.

On the down-side, I understand the concern about code maintainability and we
are ready to maintain any code changes that are added for V8.

Please let me know your suggestions, concerns, comments and feedback, we
will try to address them and conclude on whether to push this patch or not.

Thanks,

On Wed, Sep 7, 2011 at 7:48 PM, Nayan Kumar K <nayankk at motorola.com> wrote:

> As promised earlier, here is the blog post with the performance results of
> V8 and JSC on an embedded target
> http://xc0ffee.wordpress.com/2011/09/07/webkit-gtk-jsc-vs-v8-performance-on-arm/. These
> results seem to favor V8, both in x86-64 bit machine and in an ARM target.
>
> Given this, please let us know your opinions in pushing these changes to
> webkit. Based on it, I will start re-factoring the patch to ease
> code-maintainability and code review.
>
> Thanks,
>
> On Sun, Aug 28, 2011 at 1:22 AM, Nayan Kumar K <nayankk at motorola.com>wrote:
>
>> Here is the performance analysis between JSC and V8 on an x86 reference
>> machine - http://xc0ffee.wordpress.com/2011/08/27/webkit-gtk-jsc-vs-v8/.
>>
>> I am also planning to benchmark the results on an arm reference board,
>> will publish the results soon.
>>
>> On Wed, Aug 3, 2011 at 10:53 PM, Nayan Kumar K <nayankk at motorola.com>wrote:
>>
>>>
>>>
>>>> We have discussed about this in the past, the conclusion was that
>>>> adding all this code without a good reason is not that interesting,
>>>> our understanding is that in big projects with long story you have to
>>>> care about the code maintainability not just adding features. It will
>>>> add more work to maintain the port and more complexity when trying to
>>>> do some things. And basically performance tests were showing we have
>>>> both
>>>> engines in the same ballpark so choosing one or the other will not
>>>> give any benefit to the user.
>>>>
>>>
>>> I agree about your concerns on code maintainability. Please note that the
>>> patch was uploaded just for feedbacks/questions/concerns (like this. :)). I
>>> believe that this patch can be further re-factored (especially the code in
>>> WeCore/GNUmakefile.am and WebCore/GNUmakefile.list.am files) so that it
>>> eases the code maintenance (which I am willing to do anyways). We could aim
>>> to push this patch with at-most isolation as possible.
>>>
>>>>
>>>> Anyway if you want to push this patch I would say the best option is
>>>> that you try to show how this is a big improvement or that it will be a
>>>> separate part of the code that will not cause any issue. But this is
>>>> just my understanding of what was the situation.
>>>>
>>>
>>> Below are the result based on a quick performance benchmarking, with
>>> 91387 of WebKit and 8745 revision of V8
>>>
>>> Benchmarking Suite : V8 benchmark suite by Google
>>> URL : http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
>>> Host machine: x86-64
>>> Score with SFX: 3454
>>> Score with V8: 8366
>>>
>>> Of-course,  judgment on performance benefit cannot be based only on V8
>>> bench-marking suite. I will provide the results with Sunspider and Dromaeo
>>> suite soon.
>>>
>>>
>>>> Btw, usually in this kind of patches the best idea before starting to
>>>> work is asking to the people that was already checking it why it was
>>>> stopped.
>>>>
>>>> Hope it helps.
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> *Nayan*
>>>
>>>
>>
>>
>> --
>> Cheers,
>> *Nayan*
>>
>>
>
>
> --
> Cheers,
>  *Nayan*
>
>


-- 
Cheers,
*Nayan*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111007/f3c7214c/attachment.html>