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

2017-09-05 Thread Filip Pizlo


> On Sep 5, 2017, at 10:51 AM, Olmstead, Don  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 
> 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  
>>> 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

2017-09-05 Thread 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

2017-09-05 Thread 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

2017-09-05 Thread 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

2017-09-05 Thread 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

2017-09-05 Thread 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
>>>