Parser performance: 10% regression in 8.8

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Parser performance: 10% regression in 8.8

Vladislav Zavialov-2
Hello ghc-devs,

This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4).

Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration.

Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done:

2. Release a new ‘happy’
3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release
4. Restore the --coerce option in GHC’s build system ‘happy’ configuration
5. Backport it to the ghc-8.8 branch

I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5.

All the best,
- Vladislav

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Parser performance: 10% regression in 8.8

Simon Marlow-7
Thanks for bringing this up.  I've merged the PR and uploaded Happy 1.19.10 to Hackage.  Can someone else look at steps 3-5?

Cheers
Simon

On Wed, 8 May 2019 at 09:51, Vladislav Zavialov <[hidden email]> wrote:
Hello ghc-devs,

This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4).

Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration.

Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done:

2. Release a new ‘happy’
3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release
4. Restore the --coerce option in GHC’s build system ‘happy’ configuration
5. Backport it to the ghc-8.8 branch

I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5.

All the best,
- Vladislav
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Parser performance: 10% regression in 8.8

Vladislav Zavialov-2
Steps 3–4 are done: https://gitlab.haskell.org/ghc/ghc/commit/684dc290563769d456b6f1c772673d64307ab072
Step 5, as it turns out, is not needed: I was mistaken and GHC 8.8 was not affected. I got confused about the releases, it’s only 8.10 that would be affected, sorry about this. However, it’s good that we merged the fix before the ghc-8.10 branch is cut, which should happen mid-June according to https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html

Thanks everyone for responding to this, I’ve got help with CI images and updating build configuration.

All the best,
- Vladislav


> On 9 May 2019, at 10:35, Simon Marlow <[hidden email]> wrote:
>
> Thanks for bringing this up.  I've merged the PR and uploaded Happy 1.19.10 to Hackage.  Can someone else look at steps 3-5?
>
> Cheers
> Simon
>
> On Wed, 8 May 2019 at 09:51, Vladislav Zavialov <[hidden email]> wrote:
> Hello ghc-devs,
>
> This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4).
>
> Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration.
>
> Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done:
>
> 1. Merge https://github.com/simonmar/happy/pull/134
> 2. Release a new ‘happy’
> 3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release
> 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration
> 5. Backport it to the ghc-8.8 branch
>
> I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5.
>
> All the best,
> - Vladislav
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs