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  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:ghc-devs-boun...@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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Simon Peyton Jones via ghc-devs]

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-boun...@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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs