GHC 8.2 generated code faster than 8.0 but slower than 7.10

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

GHC 8.2 generated code faster than 8.0 but slower than 7.10

Harendra Kumar
Unicode normalization library (https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results:

GHC 7.10.3:

benchmarking unicode-transforms-text/NFD/English
time                 4.823 ms   (4.765 ms .. 4.902 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.46 ms   (16.24 ms .. 16.78 ms)


GHC 8.0.1


benchmarking unicode-transforms-text/NFD/English
time                 6.330 ms   (6.232 ms .. 6.439 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 18.02 ms   (17.77 ms .. 18.22 ms)

GHC 8.2.1


benchmarking unicode-transforms-text/NFD/English
time                 5.659 ms   (5.594 ms .. 5.740 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.48 ms   (16.30 ms .. 16.69 ms)

This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly.

I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement.

Thanks,
Harendra

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

RE: GHC 8.2 generated code faster than 8.0 but slower than 7.10

GHC - devs mailing list

Thanks.  Could you open a Trac ticket, and explain carefully how to reproduce your results?

 

Surely 8.4 should be faster than 7.10!

 

Simon

 

From: ghc-devs [mailto:[hidden email]] On Behalf Of Harendra Kumar
Sent: 01 August 2017 10:46
To: [hidden email]
Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10

 

Unicode normalization library (https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results:

 

GHC 7.10.3:

benchmarking unicode-transforms-text/NFD/English
time                 4.823 ms   (4.765 ms .. 4.902 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.46 ms   (16.24 ms .. 16.78 ms)


GHC 8.0.1


benchmarking unicode-transforms-text/NFD/English
time                 6.330 ms   (6.232 ms .. 6.439 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 18.02 ms   (17.77 ms .. 18.22 ms)

GHC 8.2.1


benchmarking unicode-transforms-text/NFD/English
time                 5.659 ms   (5.594 ms .. 5.740 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.48 ms   (16.30 ms .. 16.69 ms)

 

This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly.

 

I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement.

 

Thanks,

Harendra


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

Re: GHC 8.2 generated code faster than 8.0 but slower than 7.10

Harendra Kumar
https://ghc.haskell.org/trac/ghc/ticket/14072

8.2.1 is (marginally) better than 7.8.4 on this benchmark, so I guess 8.4 can be better than 7.10.3.

-harendra

On 1 August 2017 at 15:42, Simon Peyton Jones <[hidden email]> wrote:

Thanks.  Could you open a Trac ticket, and explain carefully how to reproduce your results?

 

Surely 8.4 should be faster than 7.10!

 

Simon

 

From: ghc-devs [mailto:[hidden email]] On Behalf Of Harendra Kumar
Sent: 01 August 2017 10:46
To: [hidden email]
Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10

 

Unicode normalization library (https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results:

 

GHC 7.10.3:

benchmarking unicode-transforms-text/NFD/English
time                 4.823 ms   (4.765 ms .. 4.902 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.46 ms   (16.24 ms .. 16.78 ms)


GHC 8.0.1


benchmarking unicode-transforms-text/NFD/English
time                 6.330 ms   (6.232 ms .. 6.439 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 18.02 ms   (17.77 ms .. 18.22 ms)

GHC 8.2.1


benchmarking unicode-transforms-text/NFD/English
time                 5.659 ms   (5.594 ms .. 5.740 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time                 16.48 ms   (16.30 ms .. 16.69 ms)

 

This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly.

 

I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement.

 

Thanks,

Harendra



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