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:ghc-devs-bounces@haskell.org] On Behalf Of Harendra Kumar
Sent: 01 August 2017 10:46
To: ghc-devs@haskell.org
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