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
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

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 release timing and future build infrastructure

[Ara Adkins]

Heya,

I very much agree with the thoughts on the variability of the release cadence. 
The following is somewhat of a stream of consciousness as I read, so please 
excuse any lack of coherence. 

When you talk about the bugs being significant blockers to the latest release I 
feel like that kind of issue isn't necessarily touched by moving to a shorter 
release cadence. In fact if we're unwilling to let certain fixes wait a release 
then it exacerbates the risk of slowing down a release. I'm not really sure 
what to do about this, other than adopting the mentality that fixes might not 
make the major release and will have to come in a point upgrade if they can't 
be merged to the release branch in time. 

Regarding the benefits of an abbreviated release cycle, we see it quite a lot 
in the rust community. There's a good amount of community involvement with the 
new releases, and new features are hotly anticipated as they often occur on a 
timescale where the enthusiasm is still there. I also feel, though this is 
purely anecdotal, that the more agile release schedule encourages community 
contributions as the tangible benefits of contributor work can be realised much 
more quickly. The number of RFCs in discussion at the moment is evidence of 
that, I feel. 

It's not all sunny, however, as having so many rapid releases means that it's 
sometimes difficult to rally the community around certain releases and feature 
sets. This is perhaps less of an issue due to the maturity of GHC and its 
ecosystem, but, like you say, it's important to find a good trade-off between 
release cadence and stability. 

Personally, I think Rust's cadence is a touch too short. On a related note, 
there's a 'checkpoints' initiative to build rallying releases that represent 
significant milestones in development [1]. This is, however, also tied into 
Rust's stability story, so only parts of it are relevant to GHC. 

In terms of automated tooling, I think there is significant benefit from it. 
Again, using rust as an example, there is cargobomb [2], a significant 
automated testing initiative that both combines packages on Cargo, and runs 
their test suites. I feel that a combination of the Stackage LTS and Nightly 
releases would provide a well-curated subset of Hackage that could possibly be 
used in a similar fashion. This hits on your item (b). 

Regarding your questions:
- In comparison to rust it can feel like there's significant delay in being 
able to really use GHC's newest features. I feel like this delay can hinder 
adoption of the features as much of the enthusiasm for them has died down by 
the time they're properly available. 
- With the advent of tools such as `stack`, the compiler upgrade process has 
almost become trivial. While not everyone uses it, it requires no more work 
than upgrading to a new LTS release and running `stack setup`. Nevertheless, I 
could imagine four upgrades a year still being okay if it was manual. 
- The three release policy is an interesting case as the question of changing 
it really comes down to how we view the GHC stability story. Personally, I 
think we want to target a time-period of stability, rather than a number of 
releases. Whether that time period is 1.5 years (assuming a six-month release 
cadence), or 3 years (rounding the current release cadence) seems like a 
totally independent discussion to me. 
- I think I've covered incentives to contribute in my discussion of Rust above. 

I hope that's useful! 

Best,
_ara

[1] https://github.com/rust-lang/rfcs/pull/2052
[2] https://github.com/rust-lang-nursery/cargobomb

> On 1 Aug 2017, at 03:19, Ben Gamari  wrote:
> 
> 
> Hello everyone,
> 
> I just posted a pair of posts on the GHC blog [1,2] laying out some
> thoughts on the GHC release cycle timing [1] and how this relates to the
> in-progress Jenkins build infrastructure [2]. When you have a some time
> feel free to give them a read and comment (either here or on the Reddit
> thread [3]).
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
> [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
> [3] 
> https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

New primitive types?

[Michal Terepeta]

Hi all,

I'm working on making it possible to pack constructor fields [1],
example:

```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
```

should only require 4 bytes for unpacked `Float` and 4 bytes for
unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
of 2 it currently does).

The diff to support packing of fields is in review [2], but to really
take advantage of it I think we need to introduce new primitive types:
- Int{8,16,32}#
- Word{8,16,32}#
along with some corresponding primops and with some other follow-up
changes like extending `PrimRep`.

Then we could use them in definitions of `Int{8,16,32}` and
`Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).

Does that sound ok with everyone? (just making sure that this makes
sense before I invest more time into this :)

Thanks,
Michal

[1] https://ghc.haskell.org/trac/ghc/ticket/13825
[2] https://phabricator.haskell.org/D3809
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Occurrence info on binders and STG

[Gabor Greif]

Hi devs!

I just had a short exchange with Joachim, he sent me to this place.

Can anybody explain how occurrence info is used in STG?

Cheers and thanks,

Gabor

-- Forwarded message --
From: Joachim Breitner 
Date: Tue, 01 Aug 2017 10:47:48 -0400
Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096)
To: Gabor Greif 

Hi,

feel free to CC the mailing list on such questions. I often don’t know
things perfectly either.

Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif:

>
> Loosely related question:

Very loosely :-)


>  - when doing STG Cse, the occurrence info is not updated when a
> wild(card)-binder is used. Is there a recommended way to re-run
> occ-analysis on STG? (I fear there is not.)

I fear that too. It the occ info used past that stage?

>  - I noticed that "wild"-binders sometimes do not appear at their
> binding site (after "of" and "{") in STG dumps. Dumping gets
> suppressed when they are deemed dead. Should STG consider occ-info at
> all?

Good questions. I remember that Simon commented on that before, but I
don’t remember where…


> oachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

code layout of cryptarithm1

[Joachim Breitner]

Hi,

if you look at
https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1
you see that it’s performance varies a lot, sometimes by 10%, between
commits should have nothing to do with performance. But most (not all!)
of the commits where the performance changes affect the runtime in some
way. I conclude that there is something about the code layout that
makes this program run faster or slower.

If anyone here enjoys tracing and understanding such low-level issues:
Here is a nice target to aim at.

(I don’t… but I’d appreciate less noise from gipeda :-))

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC release timing and future build infrastructure

[Brandon Allbery]

On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari  wrote:

> I just posted a pair of posts on the GHC blog [1,2] laying out some
> thoughts on the GHC release cycle timing [1] and how this relates to the
> in-progress Jenkins build infrastructure [2]. When you have a some time
> feel free to give them a read and comment (either here or on the Reddit
> thread [3]).
>

This release was actually a bit unusual for recent releases, in that a
significant delay did *not* come from working around a major breaking
behavior change in a Tier 1 platform; recent examples being macOS's load
commands limit and Ubuntu defaulting to position-independent executables.

I think this might be relevant to the question of slipping extra stuff into
releases: it's become so common to have extra time courtesy of Tier 1
platforms breaking things on us that slipping extra stuff in is now
expected.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Carter Schonwald]

One issue with packed fields is that on many architectures you can't quite
do subword reads or  writes.  So it might not always be a win.

There's also the issue that c-- as it exists in ghc doesn't have any notion
of subword sized types.

That said, I do support making word/int64/32 # types more first class /
built in.  (I hit some issues which tie into this topic in the process of
working on my still in progress safeword package. )

Point being: I support improving what we have, but it's got a bit of
surface area.  Please let me know how I can help you dig into this though

On Tue, Aug 1, 2017 at 9:37 AM Michal Terepeta 
wrote:

> Hi all,
>
> I'm working on making it possible to pack constructor fields [1],
> example:
>
> ```
> data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
> ```
>
> should only require 4 bytes for unpacked `Float` and 4 bytes for
> unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
> of 2 it currently does).
>
> The diff to support packing of fields is in review [2], but to really
> take advantage of it I think we need to introduce new primitive types:
> - Int{8,16,32}#
> - Word{8,16,32}#
> along with some corresponding primops and with some other follow-up
> changes like extending `PrimRep`.
>
> Then we could use them in definitions of `Int{8,16,32}` and
> `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).
>
> Does that sound ok with everyone? (just making sure that this makes
> sense before I invest more time into this :)
>
> Thanks,
> Michal
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/13825
> [2] https://phabricator.haskell.org/D3809
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

dataToTag# documentation

[David Feuer]

dataToTag# is documented as getting the tag number of an enumeration,
which is perfectly reasonable because it's designed to support deriving Enum.
But it *appears* to work also for non-enumeration datatypes:

dataToTag# Nothing = 0#
dataToTag# (Just 3) = 1#

Does this actually always work? If so, should that be documented, or is there
a realistic possibility that its behavior will change in the future?

Additionally: the documentation for dataToTag# urges readers to use
GHC.Base.getTag instead. But dataToTag# is exported from the "public"
GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts,
or change the documentation for dataToTag#?

David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs