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

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

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

dataToTag# documentation

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,

Occurrence info on binders and STG

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

code layout of cryptarithm1

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.

Re: GHC release timing and future build infrastructure

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

New primitive types?

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

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

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

Re: GHC release timing and future build infrastructure

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 >

Re: New primitive types?

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