Re: [webkit-dev] Bring back ARMv6 support to JSC

[Guillaume Emont]

Quoting Filip Pizlo (2017-09-05 10:37:16)
> There isn’t anyone maintaining the 32-not JIT ports to the level of quality 
> we have in our 64-not ports. Making 32-bit use the 64-bit cloop would be a 
> quality progression for actual users of 32-bit. 
> 

Hi,

I would like to chip in as one of the few people that tries to keep the
JIT afloat on mips32, and also advising Caio for the armv6 port. I agree
that support for this is a bit under-resourced (and we at Igalia are
trying to see if we can do something about it), which means that the
mips port tends to lag behind, and only works decently at some points in
time. These points in time mean that WebKit can be relevant on this
platform though. WPE works pretty well on mips, and there is a strong
interest to use it on mips and armv7 set-top-box environments.

If we drop the JIT support, I am afraid that we will lose the
performances that allow WebKit to be relevant for these applications.  I
am working on doing some measurements in real-world applications to
understand how they will be affected exactly and I will report back.

Cheers,

Guillaume


> -Filip
> 
> > On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro  
> > wrote:
> > 
> >> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba 
> >>  wrote:
> >> 
> >> [...]
> >> 
> >> Maybe it will be hard to say good bye to 32-bit architecutres
> >> for many people, but please, it's 2017 now, the first ARMv8 SoC
> >> is out 4 years ago, the first AMD64 CPU is out 14 years ago.
> > 
> > While it's true that amd64/x86_64 has been around long enough to not have to
> > care (much) about its 32-bit counterpart; the same cannot be said about ARM.
> > It would be great to be able to say that 32-bit ARM is well dead, but we are
> > not there yet.
> > 
> > If we take x86_64 as an example, it has been “only” 10 years since the last
> > new 32-bit CPU was announced and until 3-4 years ago it wasn't uncommon to
> > see plently of people running 32-bit userlands. If things unroll in a 
> > similar
> > way in the ARM arena, I would expect good 32-bit ARM support being relevant
> > at least for another 3-4 years before the need starts to fade away.
> > 
> > If something, I think it may make more sense to remove 32-bit x86 support,
> > and have the 32-bit ARM support around for some more time.
> > 
> > Cheers,
> > 
> > 
> > --
> > Adrián 
> > 
> > ___
> > 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Yusuke SUZUKI]

On Wed, Sep 6, 2017 at 3:24 AM, Filip Pizlo <fpi...@apple.com> wrote:

>
>
> > On Sep 5, 2017, at 10:51 AM, Olmstead, Don <don.olmst...@sony.com>
> wrote:
> >
> > We have plans to add a JSC-Only windows bot in the very near future.
> Would that have any bearing on the state of JIT in Windows?
>
> Not really.
>
> Because of the poor state of that code, I think we should rip it out.
>
> Also maintaining the 32_64 value representation is no value for us.
>

I think keeping Windows support would be good. I believe Sony folks are
working on Windows improvement, and it would be fine if they can keep
watching JSC on Windows.
And it means that we can keep WebKit fast at major latest architectures
including macOS / Linux / Windows (with 64bit CPUs), which is fine.

My largest concern about dropping JIT for various platforms is that LLInt
performance would be not good compared to JIT-ed environment.
We could remove DFG for 32bit (not sure). But I think PolyIC can be
critical for performance.
JS performance largely depends on this feature.

BTW, I strongly agree that newer feature should focus on 64bit
architecture. (I'm opposed to adding 32bit support to FTL).



>
> -Filip
>
>
> >
> > -Original Message-
> > From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf
> Of Filip Pizlo
> > Sent: Tuesday, September 5, 2017 8:37 AM
> > To: Adrian Perez de Castro <ape...@igalia.com>
> > Cc: webkit-dev@lists.webkit.org
> > Subject: Re: [webkit-dev] Bring back ARMv6 support to JSC
> >
> > There isn’t anyone maintaining the 32-not JIT ports to the level of
> quality we have in our 64-not ports. Making 32-bit use the 64-bit cloop
> would be a quality progression for actual users of 32-bit.
> >
> > -Filip
> >
> >>> On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro <ape...@igalia.com>
> wrote:
> >>>
> >>> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba <
> o...@inf.u-szeged.hu> wrote:
> >>>
> >>> [...]
> >>>
> >>> Maybe it will be hard to say good bye to 32-bit architecutres for
> >>> many people, but please, it's 2017 now, the first ARMv8 SoC is out 4
> >>> years ago, the first AMD64 CPU is out 14 years ago.
> >>
> >> While it's true that amd64/x86_64 has been around long enough to not
> >> have to care (much) about its 32-bit counterpart; the same cannot be
> said about ARM.
> >> It would be great to be able to say that 32-bit ARM is well dead, but
> >> we are not there yet.
> >>
> >> If we take x86_64 as an example, it has been “only” 10 years since the
> >> last new 32-bit CPU was announced and until 3-4 years ago it wasn't
> >> uncommon to see plently of people running 32-bit userlands. If things
> >> unroll in a similar way in the ARM arena, I would expect good 32-bit
> >> ARM support being relevant at least for another 3-4 years before the
> need starts to fade away.
> >>
> >> If something, I think it may make more sense to remove 32-bit x86
> >> support, and have the 32-bit ARM support around for some more time.
> >>
> >> Cheers,
> >>
> >>
> >> --
> >> Adrián 
> >>
> >> ___
> >> 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
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

> On Sep 5, 2017, at 10:51 AM, Olmstead, Don <don.olmst...@sony.com> wrote:
> 
> We have plans to add a JSC-Only windows bot in the very near future. Would 
> that have any bearing on the state of JIT in Windows?

Not really. 

Because of the poor state of that code, I think we should rip it out.

Also maintaining the 32_64 value representation is no value for us. 

-Filip


> 
> -Original Message-
> From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
> Filip Pizlo
> Sent: Tuesday, September 5, 2017 8:37 AM
> To: Adrian Perez de Castro <ape...@igalia.com>
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Bring back ARMv6 support to JSC
> 
> There isn’t anyone maintaining the 32-not JIT ports to the level of quality 
> we have in our 64-not ports. Making 32-bit use the 64-bit cloop would be a 
> quality progression for actual users of 32-bit. 
> 
> -Filip
> 
>>> On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro <ape...@igalia.com> 
>>> wrote:
>>> 
>>> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba <o...@inf.u-szeged.hu> 
>>> wrote:
>>> 
>>> [...]
>>> 
>>> Maybe it will be hard to say good bye to 32-bit architecutres for 
>>> many people, but please, it's 2017 now, the first ARMv8 SoC is out 4 
>>> years ago, the first AMD64 CPU is out 14 years ago.
>> 
>> While it's true that amd64/x86_64 has been around long enough to not 
>> have to care (much) about its 32-bit counterpart; the same cannot be said 
>> about ARM.
>> It would be great to be able to say that 32-bit ARM is well dead, but 
>> we are not there yet.
>> 
>> If we take x86_64 as an example, it has been “only” 10 years since the 
>> last new 32-bit CPU was announced and until 3-4 years ago it wasn't 
>> uncommon to see plently of people running 32-bit userlands. If things 
>> unroll in a similar way in the ARM arena, I would expect good 32-bit 
>> ARM support being relevant at least for another 3-4 years before the need 
>> starts to fade away.
>> 
>> If something, I think it may make more sense to remove 32-bit x86 
>> support, and have the 32-bit ARM support around for some more time.
>> 
>> Cheers,
>> 
>> 
>> --
>> Adrián 
>> 
>> ___
>> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

There isn’t anyone maintaining the 32-not JIT ports to the level of quality we 
have in our 64-not ports. Making 32-bit use the 64-bit cloop would be a quality 
progression for actual users of 32-bit. 

-Filip

> On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro  wrote:
> 
>> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba  
>> wrote:
>> 
>> [...]
>> 
>> Maybe it will be hard to say good bye to 32-bit architecutres
>> for many people, but please, it's 2017 now, the first ARMv8 SoC
>> is out 4 years ago, the first AMD64 CPU is out 14 years ago.
> 
> While it's true that amd64/x86_64 has been around long enough to not have to
> care (much) about its 32-bit counterpart; the same cannot be said about ARM.
> It would be great to be able to say that 32-bit ARM is well dead, but we are
> not there yet.
> 
> If we take x86_64 as an example, it has been “only” 10 years since the last
> new 32-bit CPU was announced and until 3-4 years ago it wasn't uncommon to
> see plently of people running 32-bit userlands. If things unroll in a similar
> way in the ARM arena, I would expect good 32-bit ARM support being relevant
> at least for another 3-4 years before the need starts to fade away.
> 
> If something, I think it may make more sense to remove 32-bit x86 support,
> and have the 32-bit ARM support around for some more time.
> 
> Cheers,
> 
> 
> --
> Adrián 
> 
> ___
> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Adrian Perez de Castro]

On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba  
wrote:

> [...]
>
> Maybe it will be hard to say good bye to 32-bit architecutres
> for many people, but please, it's 2017 now, the first ARMv8 SoC
> is out 4 years ago, the first AMD64 CPU is out 14 years ago.

While it's true that amd64/x86_64 has been around long enough to not have to
care (much) about its 32-bit counterpart; the same cannot be said about ARM.
It would be great to be able to say that 32-bit ARM is well dead, but we are
not there yet.

If we take x86_64 as an example, it has been “only” 10 years since the last
new 32-bit CPU was announced and until 3-4 years ago it wasn't uncommon to
see plently of people running 32-bit userlands. If things unroll in a similar
way in the ARM arena, I would expect good 32-bit ARM support being relevant
at least for another 3-4 years before the need starts to fade away.

If something, I think it may make more sense to remove 32-bit x86 support,
and have the 32-bit ARM support around for some more time.

Cheers,


--
 Adrián 



pgpfmZnBhMI9l.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Osztrogonác Csaba]

Hi,

I expected exactly this proposal when Apple announced the 64-bit
only iOS 11 near 3 months ago. ( I should have bet. :) )

I can understand that 32-bit is only an unnecessary barrier
for you and you don't want to bear the maintenance cost of it
when there isn't a significant amount of contributors for
maintaining and active developing 32-bit backends.

Maybe it will be hard to say good bye to 32-bit architecutres
for many people, but please, it's 2017 now, the first ARMv8 SoC
is out 4 years ago, the first AMD64 CPU is out 14 years ago.

br,
Ossy

On 2017.09.05. 15:51, Filip Pizlo wrote:

I think that JIT support on platforms that don’t get regular tuning doesn’t 
make sense. I think we should:

- Remove JIT support for 32-bit platforms
- Remove JIT support for Windows
- Remove JSVALUE32_64
- Use cloop In 64-bit mode on 32-bit platforms and Windows.

I think this approach would be best for the project since it would mean less 
time spent on JIT ports that are never quite done.

-Filip

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

I think that JIT support on platforms that don’t get regular tuning doesn’t 
make sense. I think we should:

- Remove JIT support for 32-bit platforms
- Remove JIT support for Windows
- Remove JSVALUE32_64
- Use cloop In 64-bit mode on 32-bit platforms and Windows. 

I think this approach would be best for the project since it would mean less 
time spent on JIT ports that are never quite done. 

-Filip

> On Sep 5, 2017, at 6:01 AM, Caio Lima  wrote:
> 
> Hi guys,I've posted this on the bug thread, but I would also like to
> revive the discussion here.
> 
> After our last discussion, I put some effort to enable IC for ARMv6
> into JIT layers and now I finally collected some results for that.
> 
> Now, we have regressions just into 2 tests in SunSpider (they aren't
> regressing in LongSpider) and 3 into Octane (gbemu, typescript and
> box2d). Also, I see regressions into microbenchmarks, mainly cases
> with observable-side-effects and set/map tests.
> 
> With these results, what do you think about keep working into ARMv6 support?
> 
> Maybe an important report is that I'm almost fixing the errors taking
> the http://trac.webkit.org/changeset/220532 as baseline. Currently
> there are ~40 tests failing, and the majority of them are due to OOM
> into my runtime env, due to memory constraints. I will try to merge it
> with current master this week to check the status of build+failures.
> 
> Regards,
> Caio.
> 
> 2017-08-01 20:52 GMT-03:00 Caio Lima :
>> Hi all.
>> 
>> FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
>> was able to find the source of the bug and apply a quick fix to run
>> benchmarks again to get results. I just ran V8Spider, Octane and
>> Kraken by now and I'm attaching the results in this email.
>> 
>> We found some test cases regressing, and my attention now is to
>> identify the reason of the regression and how to fix them. Also, the
>> improvements got with JIT in ARMv6 aren't as big as Filip commented in
>> [1] to supported architectures.
>> 
>> [1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9
>> 
>> 2017-07-13 19:27 GMT-03:00 Caio Lima :
>>> Yes. It probably will take a while to process on device, but I'll run it.
>>> 
>>> Em qui, 13 de jul de 2017 às 17:50, Saam barati 
>>> escreveu:
 
 And ARES6.
 
 - Saam
 
 
 On Jul 13, 2017, at 1:50 PM, Saam barati  wrote:
 
 Can you please run Octane and Kraken too?
 
 - Saam
 
 On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
 
 Finally I got the results from the last benchmark run. The results
 shows that the speed-ups are considerable comparing with CLoop
 version, since we get faster results in a big number of tests and
 regress in a minor number of scripts. I would like to get feedback
 from you as well, but IMHO enabling JIT for ARMv6 looks a good
 improvement step and the amount of code we are touching in current
 trunk code to make it possible is small.
 
 The results are attached and I also uploaded them in
 https://bugs.webkit.org/show_bug.cgi?id=172765.
 
 PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
 bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
 already investigating the source of problem to fix them.
 
 Regards,
 Caio.
 
 2017-07-05 22:54 GMT-03:00 Filip Pizlo :
 
 To be clear, I’m concerned that the 32-bit JIT backends have such bad
 tuning for these embedded platforms that it’s just pure badness. Until you
 can prove that you can change this, I think that porting should focus on
 making the cloop great. Then, we can rip out support for weird CPUs rather
 than bringing it back.
 
 -Filip
 
 On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
 
 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
 
 You need to establish that the JIT is a performance progression over the
 LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
 some evidence provided that you’re actually getting speed-ups.
 
 
 It makes sense. I can get these numbers related to JIT.
 
 BTW, there is a Patch that isn't JIT related
 (https://bugs.webkit.org/show_bug.cgi?id=172766).
 
 Regards,
 Caio.
 
 -Filip
 
 On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
 
 Hi All.
 
 Some of you guys might know me through the work I have been doing in
 JSC. The experience working with WebKit has been great so far, thank
 you for the reviews!
 
 Since 1st May, we at Igalia have been working on bring back the ARMv6
 support into JSC. We already have commits into our downstream branch
 port[2] that fixes some compile/runtime errors 

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi guys,I've posted this on the bug thread, but I would also like to
revive the discussion here.

After our last discussion, I put some effort to enable IC for ARMv6
into JIT layers and now I finally collected some results for that.

Now, we have regressions just into 2 tests in SunSpider (they aren't
regressing in LongSpider) and 3 into Octane (gbemu, typescript and
box2d). Also, I see regressions into microbenchmarks, mainly cases
with observable-side-effects and set/map tests.

With these results, what do you think about keep working into ARMv6 support?

Maybe an important report is that I'm almost fixing the errors taking
the http://trac.webkit.org/changeset/220532 as baseline. Currently
there are ~40 tests failing, and the majority of them are due to OOM
into my runtime env, due to memory constraints. I will try to merge it
with current master this week to check the status of build+failures.

Regards,
Caio.

2017-08-01 20:52 GMT-03:00 Caio Lima :
> Hi all.
>
> FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
> was able to find the source of the bug and apply a quick fix to run
> benchmarks again to get results. I just ran V8Spider, Octane and
> Kraken by now and I'm attaching the results in this email.
>
> We found some test cases regressing, and my attention now is to
> identify the reason of the regression and how to fix them. Also, the
> improvements got with JIT in ARMv6 aren't as big as Filip commented in
> [1] to supported architectures.
>
> [1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9
>
> 2017-07-13 19:27 GMT-03:00 Caio Lima :
>> Yes. It probably will take a while to process on device, but I'll run it.
>>
>> Em qui, 13 de jul de 2017 às 17:50, Saam barati 
>> escreveu:
>>>
>>> And ARES6.
>>>
>>> - Saam
>>>
>>>
>>> On Jul 13, 2017, at 1:50 PM, Saam barati  wrote:
>>>
>>> Can you please run Octane and Kraken too?
>>>
>>> - Saam
>>>
>>> On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
>>>
>>> Finally I got the results from the last benchmark run. The results
>>> shows that the speed-ups are considerable comparing with CLoop
>>> version, since we get faster results in a big number of tests and
>>> regress in a minor number of scripts. I would like to get feedback
>>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>>> improvement step and the amount of code we are touching in current
>>> trunk code to make it possible is small.
>>>
>>> The results are attached and I also uploaded them in
>>> https://bugs.webkit.org/show_bug.cgi?id=172765.
>>>
>>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>>> already investigating the source of problem to fix them.
>>>
>>> Regards,
>>> Caio.
>>>
>>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo :
>>>
>>> To be clear, I’m concerned that the 32-bit JIT backends have such bad
>>> tuning for these embedded platforms that it’s just pure badness. Until you
>>> can prove that you can change this, I think that porting should focus on
>>> making the cloop great. Then, we can rip out support for weird CPUs rather
>>> than bringing it back.
>>>
>>> -Filip
>>>
>>> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>>>
>>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
>>>
>>> You need to establish that the JIT is a performance progression over the
>>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
>>> some evidence provided that you’re actually getting speed-ups.
>>>
>>>
>>> It makes sense. I can get these numbers related to JIT.
>>>
>>> BTW, there is a Patch that isn't JIT related
>>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>>
>>> Regards,
>>> Caio.
>>>
>>> -Filip
>>>
>>> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
>>>
>>> Hi All.
>>>
>>> Some of you guys might know me through the work I have been doing in
>>> JSC. The experience working with WebKit has been great so far, thank
>>> you for the reviews!
>>>
>>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>>> support into JSC. We already have commits into our downstream branch
>>> port[2] that fixes some compile/runtime errors when building JSC to
>>> ARMv6 and also fixes some bugs. However, this branch is not synced
>>> with WebKit upstream tree and I would like to pursue the upstreaming
>>> of this ARMv6/JSC support to WebKit.
>>>
>>> As a long shot, we are planning to maintain the ARMv6 support and make
>>> tests run as green as possible. Also, it's our goal make ARMv6 support
>>> not interfere with other ARM versions support code negatively and we
>>> will be in charge of implement platform-specific fixes/features for
>>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>>
>>> To keep track of work to be done, I've create a meta-bug in
>>> 

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi all.

FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
was able to find the source of the bug and apply a quick fix to run
benchmarks again to get results. I just ran V8Spider, Octane and
Kraken by now and I'm attaching the results in this email.

We found some test cases regressing, and my attention now is to
identify the reason of the regression and how to fix them. Also, the
improvements got with JIT in ARMv6 aren't as big as Filip commented in
[1] to supported architectures.

[1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9

2017-07-13 19:27 GMT-03:00 Caio Lima :
> Yes. It probably will take a while to process on device, but I'll run it.
>
> Em qui, 13 de jul de 2017 às 17:50, Saam barati 
> escreveu:
>>
>> And ARES6.
>>
>> - Saam
>>
>>
>> On Jul 13, 2017, at 1:50 PM, Saam barati  wrote:
>>
>> Can you please run Octane and Kraken too?
>>
>> - Saam
>>
>> On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
>>
>> Finally I got the results from the last benchmark run. The results
>> shows that the speed-ups are considerable comparing with CLoop
>> version, since we get faster results in a big number of tests and
>> regress in a minor number of scripts. I would like to get feedback
>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>> improvement step and the amount of code we are touching in current
>> trunk code to make it possible is small.
>>
>> The results are attached and I also uploaded them in
>> https://bugs.webkit.org/show_bug.cgi?id=172765.
>>
>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>> already investigating the source of problem to fix them.
>>
>> Regards,
>> Caio.
>>
>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo :
>>
>> To be clear, I’m concerned that the 32-bit JIT backends have such bad
>> tuning for these embedded platforms that it’s just pure badness. Until you
>> can prove that you can change this, I think that porting should focus on
>> making the cloop great. Then, we can rip out support for weird CPUs rather
>> than bringing it back.
>>
>> -Filip
>>
>> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>>
>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
>>
>> You need to establish that the JIT is a performance progression over the
>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
>> some evidence provided that you’re actually getting speed-ups.
>>
>>
>> It makes sense. I can get these numbers related to JIT.
>>
>> BTW, there is a Patch that isn't JIT related
>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>
>> Regards,
>> Caio.
>>
>> -Filip
>>
>> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
>>
>> Hi All.
>>
>> Some of you guys might know me through the work I have been doing in
>> JSC. The experience working with WebKit has been great so far, thank
>> you for the reviews!
>>
>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>> support into JSC. We already have commits into our downstream branch
>> port[2] that fixes some compile/runtime errors when building JSC to
>> ARMv6 and also fixes some bugs. However, this branch is not synced
>> with WebKit upstream tree and I would like to pursue the upstreaming
>> of this ARMv6/JSC support to WebKit.
>>
>> As a long shot, we are planning to maintain the ARMv6 support and make
>> tests run as green as possible. Also, it's our goal make ARMv6 support
>> not interfere with other ARM versions support code negatively and we
>> will be in charge of implement platform-specific fixes/features for
>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>
>> To keep track of work to be done, I've create a meta-bug in
>> bugzilla[3] and it's going to be used firstly to organize the commits
>> from our downstream branch, but pretty soon I'm going to create issues
>> related with javascriptcore-test failures and send patches to fix
>> them. We have already submitted 3 patches (they are marked as
>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>> a round of review into them.
>>
>> Best Regards,
>> Caio.
>>
>> [1] - https://www.igalia.com/about-us/coding-experience
>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>> ___
>> 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
>>
>>
>>
>
Benchmark report for Octane and Kraken on buildroot.

VMs tested:
"baseline" at /home/igalia/clima/webkit/WebKitBaselineBuild/Release/bin/jsc
"changes" at 

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Yes. It probably will take a while to process on device, but I'll run it.

Em qui, 13 de jul de 2017 às 17:50, Saam barati 
escreveu:

> And ARES6.
>
> - Saam
>
>
> On Jul 13, 2017, at 1:50 PM, Saam barati  wrote:
>
> Can you please run Octane and Kraken too?
>
> - Saam
>
> On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
>
> Finally I got the results from the last benchmark run. The results
> shows that the speed-ups are considerable comparing with CLoop
> version, since we get faster results in a big number of tests and
> regress in a minor number of scripts. I would like to get feedback
> from you as well, but IMHO enabling JIT for ARMv6 looks a good
> improvement step and the amount of code we are touching in current
> trunk code to make it possible is small.
>
> The results are attached and I also uploaded them in
> https://bugs.webkit.org/show_bug.cgi?id=172765.
>
> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
> already investigating the source of problem to fix them.
>
> Regards,
> Caio.
>
> 2017-07-05 22:54 GMT-03:00 Filip Pizlo :
>
> To be clear, I’m concerned that the 32-bit JIT backends have such bad
> tuning for these embedded platforms that it’s just pure badness. Until you
> can prove that you can change this, I think that porting should focus on
> making the cloop great. Then, we can rip out support for weird CPUs rather
> than bringing it back.
>
> -Filip
>
> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>
> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
>
> You need to establish that the JIT is a performance progression over the
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
> some evidence provided that you’re actually getting speed-ups.
>
>
> It makes sense. I can get these numbers related to JIT.
>
> BTW, there is a Patch that isn't JIT related
> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>
> Regards,
> Caio.
>
> -Filip
>
> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
>
> Hi All.
>
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
>
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
>
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
>
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
>
> Best Regards,
> Caio.
>
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>  buildroot_20170712_1029_report.txt>___
> 
> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Saam barati]

And ARES6.

- Saam

> On Jul 13, 2017, at 1:50 PM, Saam barati  wrote:
> 
> Can you please run Octane and Kraken too?
> 
> - Saam
> 
>> On Jul 13, 2017, at 7:47 AM, Caio Lima > > wrote:
>> 
>> Finally I got the results from the last benchmark run. The results
>> shows that the speed-ups are considerable comparing with CLoop
>> version, since we get faster results in a big number of tests and
>> regress in a minor number of scripts. I would like to get feedback
>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>> improvement step and the amount of code we are touching in current
>> trunk code to make it possible is small.
>> 
>> The results are attached and I also uploaded them in
>> https://bugs.webkit.org/show_bug.cgi?id=172765 
>> .
>> 
>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>> already investigating the source of problem to fix them.
>> 
>> Regards,
>> Caio.
>> 
>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo > >:
>>> To be clear, I’m concerned that the 32-bit JIT backends have such bad 
>>> tuning for these embedded platforms that it’s just pure badness. Until you 
>>> can prove that you can change this, I think that porting should focus on 
>>> making the cloop great. Then, we can rip out support for weird CPUs rather 
>>> than bringing it back.
>>> 
>>> -Filip
>>> 
 On Jul 5, 2017, at 6:14 PM, Caio Lima > wrote:
 
 2017-07-05 18:25 GMT-03:00 Filip Pizlo >:
> You need to establish that the JIT is a performance progression over the 
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
> some evidence provided that you’re actually getting speed-ups.
 
 It makes sense. I can get these numbers related to JIT.
 
 BTW, there is a Patch that isn't JIT related
 (https://bugs.webkit.org/show_bug.cgi?id=172766 
 ).
 
 Regards,
 Caio.
 
> -Filip
> 
>> On Jun 13, 2017, at 6:48 PM, Caio Lima > > wrote:
>> 
>> Hi All.
>> 
>> Some of you guys might know me through the work I have been doing in
>> JSC. The experience working with WebKit has been great so far, thank
>> you for the reviews!
>> 
>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>> support into JSC. We already have commits into our downstream branch
>> port[2] that fixes some compile/runtime errors when building JSC to
>> ARMv6 and also fixes some bugs. However, this branch is not synced
>> with WebKit upstream tree and I would like to pursue the upstreaming
>> of this ARMv6/JSC support to WebKit.
>> 
>> As a long shot, we are planning to maintain the ARMv6 support and make
>> tests run as green as possible. Also, it's our goal make ARMv6 support
>> not interfere with other ARM versions support code negatively and we
>> will be in charge of implement platform-specific fixes/features for
>> JSC/ARM6, this way no imposing burden to the rest of the community.
>> 
>> To keep track of work to be done, I've create a meta-bug in
>> bugzilla[3] and it's going to be used firstly to organize the commits
>> from our downstream branch, but pretty soon I'm going to create issues
>> related with javascriptcore-test failures and send patches to fix
>> them. We have already submitted 3 patches (they are marked as
>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>> a round of review into them.
>> 
>> Best Regards,
>> Caio.
>> 
>> [1] - https://www.igalia.com/about-us/coding-experience 
>> 
>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit 
>> 
>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765 
>> 
>> ___
>> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Saam barati]

Can you please run Octane and Kraken too?

- Saam

> On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
> 
> Finally I got the results from the last benchmark run. The results
> shows that the speed-ups are considerable comparing with CLoop
> version, since we get faster results in a big number of tests and
> regress in a minor number of scripts. I would like to get feedback
> from you as well, but IMHO enabling JIT for ARMv6 looks a good
> improvement step and the amount of code we are touching in current
> trunk code to make it possible is small.
> 
> The results are attached and I also uploaded them in
> https://bugs.webkit.org/show_bug.cgi?id=172765 
> .
> 
> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
> already investigating the source of problem to fix them.
> 
> Regards,
> Caio.
> 
> 2017-07-05 22:54 GMT-03:00 Filip Pizlo  >:
>> To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning 
>> for these embedded platforms that it’s just pure badness. Until you can 
>> prove that you can change this, I think that porting should focus on making 
>> the cloop great. Then, we can rip out support for weird CPUs rather than 
>> bringing it back.
>> 
>> -Filip
>> 
>>> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>>> 
>>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
 You need to establish that the JIT is a performance progression over the 
 LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
 some evidence provided that you’re actually getting speed-ups.
>>> 
>>> It makes sense. I can get these numbers related to JIT.
>>> 
>>> BTW, there is a Patch that isn't JIT related
>>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>> 
>>> Regards,
>>> Caio.
>>> 
 -Filip
 
> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
> 
> Hi All.
> 
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
> 
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
> 
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
> 
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
> 
> Best Regards,
> Caio.
> 
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

The fact that V8Spider is regressed indicates major problems with the JIT on 
ARMv6. 

I think that it would be better to work on fixing this JIT outside trunk, and 
then come back with patches once you have a speed up. In the future we 
shouldn’t allow partially-working JIT ports to land.

-Filip

> On Jul 13, 2017, at 7:47 AM, Caio Lima  wrote:
> 
> Finally I got the results from the last benchmark run. The results
> shows that the speed-ups are considerable comparing with CLoop
> version, since we get faster results in a big number of tests and
> regress in a minor number of scripts. I would like to get feedback
> from you as well, but IMHO enabling JIT for ARMv6 looks a good
> improvement step and the amount of code we are touching in current
> trunk code to make it possible is small.
> 
> The results are attached and I also uploaded them in
> https://bugs.webkit.org/show_bug.cgi?id=172765.
> 
> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
> already investigating the source of problem to fix them.
> 
> Regards,
> Caio.
> 
> 2017-07-05 22:54 GMT-03:00 Filip Pizlo :
>> To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning 
>> for these embedded platforms that it’s just pure badness. Until you can 
>> prove that you can change this, I think that porting should focus on making 
>> the cloop great. Then, we can rip out support for weird CPUs rather than 
>> bringing it back.
>> 
>> -Filip
>> 
>>> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>>> 
>>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
 You need to establish that the JIT is a performance progression over the 
 LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
 some evidence provided that you’re actually getting speed-ups.
>>> 
>>> It makes sense. I can get these numbers related to JIT.
>>> 
>>> BTW, there is a Patch that isn't JIT related
>>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>> 
>>> Regards,
>>> Caio.
>>> 
 -Filip
 
> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
> 
> Hi All.
> 
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
> 
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
> 
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
> 
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
> 
> Best Regards,
> Caio.
> 
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Finally I got the results from the last benchmark run. The results
shows that the speed-ups are considerable comparing with CLoop
version, since we get faster results in a big number of tests and
regress in a minor number of scripts. I would like to get feedback
from you as well, but IMHO enabling JIT for ARMv6 looks a good
improvement step and the amount of code we are touching in current
trunk code to make it possible is small.

The results are attached and I also uploaded them in
https://bugs.webkit.org/show_bug.cgi?id=172765.

PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
already investigating the source of problem to fix them.

Regards,
Caio.

2017-07-05 22:54 GMT-03:00 Filip Pizlo :
> To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning 
> for these embedded platforms that it’s just pure badness. Until you can prove 
> that you can change this, I think that porting should focus on making the 
> cloop great. Then, we can rip out support for weird CPUs rather than bringing 
> it back.
>
> -Filip
>
>> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
>>
>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
>>> You need to establish that the JIT is a performance progression over the 
>>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
>>> some evidence provided that you’re actually getting speed-ups.
>>
>> It makes sense. I can get these numbers related to JIT.
>>
>> BTW, there is a Patch that isn't JIT related
>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>
>> Regards,
>> Caio.
>>
>>> -Filip
>>>
 On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:

 Hi All.

 Some of you guys might know me through the work I have been doing in
 JSC. The experience working with WebKit has been great so far, thank
 you for the reviews!

 Since 1st May, we at Igalia have been working on bring back the ARMv6
 support into JSC. We already have commits into our downstream branch
 port[2] that fixes some compile/runtime errors when building JSC to
 ARMv6 and also fixes some bugs. However, this branch is not synced
 with WebKit upstream tree and I would like to pursue the upstreaming
 of this ARMv6/JSC support to WebKit.

 As a long shot, we are planning to maintain the ARMv6 support and make
 tests run as green as possible. Also, it's our goal make ARMv6 support
 not interfere with other ARM versions support code negatively and we
 will be in charge of implement platform-specific fixes/features for
 JSC/ARM6, this way no imposing burden to the rest of the community.

 To keep track of work to be done, I've create a meta-bug in
 bugzilla[3] and it's going to be used firstly to organize the commits
 from our downstream branch, but pretty soon I'm going to create issues
 related with javascriptcore-test failures and send patches to fix
 them. We have already submitted 3 patches (they are marked as
 dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
 a round of review into them.

 Best Regards,
 Caio.

 [1] - https://www.igalia.com/about-us/coding-experience
 [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
 [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
Benchmark report for SunSpider, LongSpider, V8Spider, Microbenchmarks, and 
SixSpeed on buildroot.

VMs tested:
"baseline" at /home/igalia/clima/webkit/WebKitBaselineBuild/Release/bin/jsc
"changes" at /home/igalia/clima/webkit/WebKitBuild/Release/bin/jsc

Collected 4 samples per benchmark/VM, with 4 VM invocations per benchmark. 
Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used 
the jsc-specific preciseTime() function to get
microsecond-level timing. Reporting benchmark execution times with 95% 
confidence intervals in milliseconds.

  baseline  
changes  
SunSpider:
   3d-cube   653.1262+-15.7953!   
1030.1705+-8.7283! definitely 1.5773x slower
   3d-morph  966.5934+-85.3047^
416.0468+-15.0777   ^ definitely 2.3233x faster
   3d-raytrace  1695.6381+-81.7207!   
2577.3122+-55.1663   ! definitely 1.5200x slower
   access-binary-trees   648.9722+-64.7831 
590.8699+-123.7847might be 1.0983x faster
   access-fannkuch   902.1701+-2.5893 ^
362.0073+-8.8704^ 

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning 
for these embedded platforms that it’s just pure badness. Until you can prove 
that you can change this, I think that porting should focus on making the cloop 
great. Then, we can rip out support for weird CPUs rather than bringing it 
back. 

-Filip

> On Jul 5, 2017, at 6:14 PM, Caio Lima  wrote:
> 
> 2017-07-05 18:25 GMT-03:00 Filip Pizlo :
>> You need to establish that the JIT is a performance progression over the 
>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
>> some evidence provided that you’re actually getting speed-ups.
> 
> It makes sense. I can get these numbers related to JIT.
> 
> BTW, there is a Patch that isn't JIT related
> (https://bugs.webkit.org/show_bug.cgi?id=172766).
> 
> Regards,
> Caio.
> 
>> -Filip
>> 
>>> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
>>> 
>>> Hi All.
>>> 
>>> Some of you guys might know me through the work I have been doing in
>>> JSC. The experience working with WebKit has been great so far, thank
>>> you for the reviews!
>>> 
>>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>>> support into JSC. We already have commits into our downstream branch
>>> port[2] that fixes some compile/runtime errors when building JSC to
>>> ARMv6 and also fixes some bugs. However, this branch is not synced
>>> with WebKit upstream tree and I would like to pursue the upstreaming
>>> of this ARMv6/JSC support to WebKit.
>>> 
>>> As a long shot, we are planning to maintain the ARMv6 support and make
>>> tests run as green as possible. Also, it's our goal make ARMv6 support
>>> not interfere with other ARM versions support code negatively and we
>>> will be in charge of implement platform-specific fixes/features for
>>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>> 
>>> To keep track of work to be done, I've create a meta-bug in
>>> bugzilla[3] and it's going to be used firstly to organize the commits
>>> from our downstream branch, but pretty soon I'm going to create issues
>>> related with javascriptcore-test failures and send patches to fix
>>> them. We have already submitted 3 patches (they are marked as
>>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>>> a round of review into them.
>>> 
>>> Best Regards,
>>> Caio.
>>> 
>>> [1] - https://www.igalia.com/about-us/coding-experience
>>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>>> ___
>>> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

2017-07-05 18:25 GMT-03:00 Filip Pizlo :
> You need to establish that the JIT is a performance progression over the 
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
> some evidence provided that you’re actually getting speed-ups.

It makes sense. I can get these numbers related to JIT.

BTW, there is a Patch that isn't JIT related
(https://bugs.webkit.org/show_bug.cgi?id=172766).

Regards,
Caio.

> -Filip
>
>> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
>>
>> Hi All.
>>
>> Some of you guys might know me through the work I have been doing in
>> JSC. The experience working with WebKit has been great so far, thank
>> you for the reviews!
>>
>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>> support into JSC. We already have commits into our downstream branch
>> port[2] that fixes some compile/runtime errors when building JSC to
>> ARMv6 and also fixes some bugs. However, this branch is not synced
>> with WebKit upstream tree and I would like to pursue the upstreaming
>> of this ARMv6/JSC support to WebKit.
>>
>> As a long shot, we are planning to maintain the ARMv6 support and make
>> tests run as green as possible. Also, it's our goal make ARMv6 support
>> not interfere with other ARM versions support code negatively and we
>> will be in charge of implement platform-specific fixes/features for
>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>
>> To keep track of work to be done, I've create a meta-bug in
>> bugzilla[3] and it's going to be used firstly to organize the commits
>> from our downstream branch, but pretty soon I'm going to create issues
>> related with javascriptcore-test failures and send patches to fix
>> them. We have already submitted 3 patches (they are marked as
>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>> a round of review into them.
>>
>> Best Regards,
>> Caio.
>>
>> [1] - https://www.igalia.com/about-us/coding-experience
>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>> ___
>> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Carlos Alberto Lopez Perez]

On 05/07/17 23:24, Saam barati wrote:
> What’s the testing plan here? Do y'all plan to add a bot that ensures ARMv6 
> stays working?
> 
> - Saam

We do.

I will deploy one at https://build-webkit.igalia.com/waterfall?category=misc
ASAP (hopefully this week), and then propose a patch to move it to the official
QA infrastructure at https://build.webkit.org/waterfall?category=misc




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Filip Pizlo]

You need to establish that the JIT is a performance progression over the LLInt 
on ARMv6. I am opposed to more ARMv6 patches landing until there is some 
evidence provided that you’re actually getting speed-ups.

-Filip

> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
> 
> Hi All.
> 
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
> 
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
> 
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
> 
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
> 
> Best Regards,
> Caio.
> 
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> 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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Saam barati]

What’s the testing plan here? Do y'all plan to add a bot that ensures ARMv6 
stays working?

- Saam

> On Jun 13, 2017, at 6:48 PM, Caio Lima  wrote:
> 
> Hi All.
> 
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
> 
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
> 
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
> 
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
> 
> Best Regards,
> Caio.
> 
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> 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