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,

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

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 >

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.

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

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

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