- ghc-devs - Haskell.org

Measuring compiler performance
by Simon Jakobi 08 Apr '20

08 Apr '20

Hi devs! I've recently started working on a few compiler perf related tickets, and wondered how to verify that a change actually has a positive impact on compiler performance. I first looked at the wiki for information on this, but didn't find much: https://gitlab.haskell.org/ghc/ghc/-/wikis/performance/compiler doesn't contain any information on how to measure compiler performance The best tip I found was the recommendation in https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-no-fib to compile nofib/spectral/simple/Main.hs. With -O0 and -O that takes respectively about 1.5s and 5s for me, so the effort is manageable. I've also done full nofib runs, but they take a very long time. A problem in this context is that reliable performance measurements require a quiet machine. Closing my browser, and turning off other programs is – in my perception – rather inconvenient, particularly when I have to do it for a prolonged time. Ideally I wouldn't have to perform these measurements on my local machine at all! Do you usually use a separate machine for this? _Very_ convenient would be some kind of bot whom I could tell e.g. @perf-bot compiler perf …or more concretely @perf-bot compile nofib/spectral/simple/Main.hs …or just @nofib-bot run … or something like that. I've noticed that CI now includes a perf-nofib job. But since it appears to run on a different machine each time, I'm not sure whether it's actually useful for comparing performance. Could it be made more useful by running it consistently on the same dedicated machine? Another question regarding performing compiler perf measurements locally is which build flavour to use: So far I have used the "perf" flavour. A problem here is that a full build seems to take close to an hour. A rebuild with --freeze1 takes ~15 minutes on my machine. Is this the right flavour to use? BTW what's the purpose of the profiled GHC modules built with this flavour which just seem to additionally prolong compile time? I don't see a ghc-prof binary or similar in _build/stage1/bin. Also, what's the status of gipeda? The most recent commit at https://perf.haskell.org/ghc/ is from "about a year ago"? Sorry for this load of questions and complaints! I do believe though that if work on compiler performance was a bit better documented and more convenient, we might see even more progress on that front. :) Cheers, Simon

6 7

Re: Uppercase OverloadedLabels
by Ryan Scott 08 Apr '20

08 Apr '20

No particular reason. There is an accepted GHC proposal to relax this restriction [1], as well as an accompanying GHC issue [2], but it has not yet been implemented. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-u… [2] https://gitlab.haskell.org/ghc/ghc/issues/11671

1 0

Targeting old Windows versions
by Andreas Klebinger 08 Apr '20

08 Apr '20

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage on versions of windows *older* than Windows 8.1/Sever 2012. Please let us know if you are targeting older versions than that either by responding to the mailing list, commenting on the ticket or contacting me directly if you have privacy concerns. Depending on how many people are affected by this change we might consider measures to reduce the impact. Cheers, Andreas

1 0

Uppercase OverloadedLabels
by Alejandro Serrano Mena 07 Apr '20

07 Apr '20

Dear Haskell-Café / GHC devs, Is there any reason why the `OverloadedHaskell` extension does not work with labels starting with an uppercase letter? Kind regards, Alejandro

1 0

Fusing loops by specializing on functions with SpecConstr?
by Alexis King 06 Apr '20

06 Apr '20

Hi all, I have recently been toying with FRP, and I’ve noticed that traditional formulations generate a lot of tiny loops that GHC does a very poor job optimizing. Here’s a simplified example: newtype SF a b = SF { runSF :: a -> (b, SF a b) } add1_snd :: SF (String, Int) (String, Int) add1_snd = second add1 where add1 = SF $ \a -> let !b = a + 1 in (b, add1) second f = SF $ \(a, b) -> let !(c, f') = runSF f b in ((a, c), second f') Here, `add1_snd` is defined in terms of two recursive bindings, `add1` and `second`. Because they’re both recursive, GHC doesn’t know what to do with them, and the optimized program still has two separate recursive knots. But this is a missed optimization, as `add1_snd` is equivalent to the following definition, which fuses the two loops together and consequently has just one recursive knot: add1_snd_fused :: SF (String, Int) (String, Int) add1_snd_fused = SF $ \(a, b) -> let !c = b + 1 in ((a, c), add1_snd_fused) How could GHC get from `add1_snd` to `add1_snd_fused`? In theory, SpecConstr could do it! Suppose we specialize `second` at the call pattern `second add1`: {-# RULE "second/add1" second add1 = second_add1 #-} second_add1 = SF $ \(a, b) -> let !(c, f') = runSF add1 b in ((a, c), second f') This doesn’t immediately look like an improvement, but we’re actually almost there. If we unroll `add1` once on the RHS of `second_add1`, the simplifier will get us the rest of the way. We’ll end up with let !b1 = b + 1 !(c, f') = (b1, add1) in ((a, c), second f') and after substituting f' to get `second add1`, the RULE will tie the knot for us. This may look like small potatoes in isolation, but real programs can generate hundreds of these tiny, tiny loops, and fusing them together would be a big win. The only problem is SpecConstr doesn’t currently specialize on functions! The original paper, “Call-pattern Specialisation for Haskell Programs,” mentions this as a possibility in Section 6.2, but it points out that actually doing this in practice would be pretty tricky: > Specialising for function arguments is more slippery than for > constructor arguments. In the example above the argument was a > simple variable, but what if it was instead a lambda term? [...] > > The trouble is that lambda abstractions are much more fragile than > constructor applications, in the sense that simple transformations > may make two abstractions look different although they have the > same value. Still, the difference this could make in a program of mine is so large that I am interested in exploring it anyway. I am wondering if anyone has investigated this possibility any further since the paper was published, or if anyone knows of other use cases that would benefit from this capability. Thanks, Alexis

5 16

Re: Building libraries with an in-place GHC
by Ryan Scott 06 Apr '20

06 Apr '20

Hi Simon, As #18018 says, you need to use head.hackage to reproduce it. This page [1] contains a rather short tutorial on how to use it, but Ben is currently drafting a more detailed tutorial on its use here [2]. This is what I use whenever building any Hackage library with GHC HEAD. Ryan S. ----- [1] https://ghc.gitlab.haskell.org/head.hackage/ [2] https://gitlab.haskell.org/ghc/homepage/-/merge_requests/29

1 0

Building libraries with an in-place GHC
by Simon Peyton Jones 06 Apr '20

06 Apr '20

Devs I want to reproduce #18018, but that needs me to build pandoc with my freshly-built HEAD. I tried this (below) but as you can see that didn't work. What should I do? Thanks Simon bash$ cabal install --with-compiler=/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2 --package-db=/home/simonpj/code/HEAD-3/inplace/lib/package.conf.d pandoc-2.9.2.1 Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: pandoc-2.9.2.1 (user goal) [__1] trying: zlib-0.6.2.1 (dependency of pandoc) [__2] trying: base-4.14.0.0/installed-4.14.0.0 (dependency of zlib) [__3] next goal: haddock-library (dependency of pandoc) [__3] rejecting: haddock-library-1.8.0 (conflict: base==4.14.0.0/installed-4.14.0.0, haddock-library => base>=4.7 && <4.14) [__3] skipping: haddock-library-1.7.0, haddock-library-1.6.0, haddock-library-1.5.0.1, haddock-library-1.4.5, haddock-library-1.4.4, haddock-library-1.4.3, haddock-library-1.4.2, haddock-library-1.4.1, haddock-library-1.2.1, haddock-library-1.2.0, haddock-library-1.1.1, haddock-library-1.1.0, haddock-library-1.0.1, haddock-library-1.0.0, haddock-library-1.6.1 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.14.0.0) [__3] fail (backjumping, conflict set: base, haddock-library, pandoc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: pandoc, base, haddock-library, zlib Try running with --minimize-conflict-set to improve the error message. bash$ cabal --version cabal-install version 3.2.0.0 compiled using version 3.2.0.0 of the Cabal library

1 0

Module Renaming: GHC.Core.Op
by Andreas Klebinger 06 Apr '20

06 Apr '20

Hello devs, While I looked at the renaming a bit when proposed I only just realized we seem to be using Op as a short name for optimize. I find this very unintuitive. Can we spare another letter to make this GHC.Core.Opt instead? We use opt pretty much everywhere else in GHC already. Cheers Andreas

5 6

Advice implementing new constraint entailment rules
by Matthew Pickering 02 Apr '20

02 Apr '20

Hello, I am attempting to implement two new constraint entailment rules which dictate how to implement a new constraint form "CodeC" can be used to satisfy constraints. The main idea is that all constraints store the level they they are introduced and required (in the Template Haskell sense of level) and that only constraints of the right level can be used. The "CodeC" constraint form allows the level of constraints to be manipulated. Therefore the two rules In order to implement this I want to add two constraint rewriting rules in the following way: 1. If in a given, `CodeC C @ n` ~> `C @ n+1` 2. If in a wanted `CodeC C @ n` -> `C @ n - 1` Can someone give me some pointers about the specific part of the constraint solver where I should add these rules? I am unsure if this rewriting of wanted constraints already occurs or not. Cheers, Matt

2 4

License for grammar
by Евгений Слободкин 01 Apr '20

01 Apr '20

Hi all! I implemented Haskell grammar for ANTLRv4 based on HaskellReport 2010 and GHC source (Parser.y and Lexer.x files). Link: https://github.com/antlr/grammars-v4/blob/master/haskell/Haskell.g4 Could someone please help me figuring out which license this grammar should be published on?

3 2