March 2021 - ghc-devs

Pointer-or-Int 63-bit representations for Integer
by Chris Done 08 Mar '21

08 Mar '21

Hi all, In OCaml's implementation, they use a well known 63-bit representation of ints to distinguish whether a given machine word is either a pointer or to be interpreted as an integer. I was wondering whether anyone had considered the performance benefits of doing this for the venerable Integer type in Haskell? I.e. if the Int fits in 63-bits, just shift it and do regular arithmetic. If the result ever exceeds 63-bits, allocate a GMP/integer-simple integer and return a pointer to it. This way, for most applications--in my experience--integers don't really ever exceed 64-bit, so you would (possibly) pay a smaller cost than the pointer chasing involved in bignum arithmetic. Assumption: it's cheaper to do more CPU instructions than to allocate or wait for mainline memory. This would need assistance from the GC to be able to recognize said bit flag. As I understand the current implementation of integer-gimp, they also try to use an Int64 where possible using a constructor (https://hackage.haskell.org/package/integer-gmp-1.0.3.0/docs/src/GHC.Intege…) but I believe that the compiled code will still pointer chase through the constructor. Simple addition or subtraction, for example, is 24 times slower in Integer than in Int for 1000000 iterations: https://github.com/haskell-perf/numbers#addition An unboxed sum might be an improvement? e.g. (# Int# | ByteArray# #) -- would this "kind of" approximate the approach described? I don't have a good intuition of what the memory layout would be like. Just pondering. Cheers, Chris

4 4

Newcomer looking for mentorship on a HPC / Coverage related issue
by Javran Cheng 03 Mar '21

03 Mar '21

Hi all, I'm a newcomer (not entirely new as I did have some contribution few years back but the workflow seems to have changed a lot) and is working on https://gitlab.haskell.org/ghc/ghc/-/issues/15932. I'm looking for some (informal) mentorship on that issue - I think I know what the problem is <https://gitlab.haskell.org/ghc/ghc/-/issues/15932#note_283252>, but I need someone with more experience to help developing a concrete plan before working on a fix, as this might involve two parts in GHC codebase: HPC source code and GHC/HsToCore/Coverage. I tried to ask for comments and other related bits on IRC few months back but that doesn't attract much attention. Now that I'm in the mood of hacking GHC again, I figure probably finding a mentorship might work better. Thanks! Javran

2 1

Plan for GHC 9.2
by Ben Gamari 03 Mar '21

03 Mar '21

tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, especially if you have something you would like merged for 9.2.1. Hello all, With GHC 9.0.1 at long-last out the door, it is time that we start turning attention to GHC 9.2. I would like to avoid making the mistake made in the 9.0 series in starting the fork in a state that required a significant amount of backporting to be releaseable. Consequently, I want to make sure that we have a fork schedule that is realistic given the things that need to be merged for 9.2. These include: * Update haddock submodule in `master` (Ben) * Bumping bytestring to 0.11 (#19091, Ben) * Finishing the rework of sized integer primops (#19026, John Ericson) * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) * Merge BoxedRep (#17526, Ben) * ARM NCG backend and further stabilize Apple ARM support? (Moritz) * Some form of coercion zapping (Ben, Simon, Richard) * Tag inference analysis and tag check elision (Andreas) If you see something that you would like to see in 9.2.1 please do holler. Otherwise, if you see your name in this list it would be great if you could let me know when you think your project may be in a mergeable state. Ideally we would strive for a schedule like the following: 4 February 2021: We are here ~4 weeks pass 3 March 2021: Release branch forked 1 week passes 10 March 2021: Alpha 1 released 3 weeks pass 31 March 2021: Alpha 2 released 2 weeks pass 14 April 2021: Alpha 3 released 2 weeks pass 28 April 2021: Alpha 4 released 1 week passes 5 May 2021: Beta 1 released 1 week passes 12 May 2021: Release candidate 1 released 2 weeks pass 26 May 2021: Final release This provides ample time for stabilization while avoiding deviation from the usual May release timeframe. However, this would require that we move aggressively to start getting the tree into shape since the fork would be less than four weeks away. I would appreciate contributors' thoughts on the viability of this timeline. Cheers, - Ben

6 7

GHC 9.1?
by Richard Eisenberg 02 Mar '21

02 Mar '21

Hi devs, I understand that GHC uses the same version numbering system as the Linux kernel did until 2003(*), using odd numbers for unstable "releases" and even ones for stable ones. I have seen this become a point of confusion, as in: "Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" "Um, what about 9.1?" Is there a reason to keep this practice? Linux moved away from it 18 years ago and seems to have thrived despite. Giving this convention up on a new first-number change (the change from 8 to 9) seems like a good time. I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time. Richard (*) I actually didn't know that Linux stopped doing this until writing this email, wondering why we needed to tie ourselves to Linux. I coincidentally stopped using Linux full-time (and thus administering my own installation) in 2003, when I graduated from university.

6 8