[webkit-gtk] Porting V8 to WebKit

Nayan Kumar K nayankk at motorola.com
Wed Sep 7 07:18:25 PDT 2011


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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20110907/7b7aa3d3/attachment.html>


More information about the webkit-gtk mailing list