- ghc-devs - Haskell.org

End of Windows Vista support in GHC-8.6?
by Simon Jakobi 09 May '18

09 May '18

Hi! Given that Vista’s EOL was in April 2017 <https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support> i assume that there’s no intention to keep supporting it in GHC-8.6!? I’m asking because I intend to use a function <https://msdn.microsoft.com/en-us/library/windows/desktop/dd405488.aspx> that requires Windows 7 or newer for #13362 <https://ghc.haskell.org/trac/ghc/ticket/13362>. Ending Vista support would also allow us to remove some workarounds <https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=Vista> mostly in RTS. Best, Simon

5 10

Basic Block Layout in the NCG
by Andreas Klebinger 08 May '18

08 May '18

Does anyone have good hints for literature on basic block layout algorithms? I've run into a few examples where the current algorithm falls apart while working on Cmm. There is a trac ticket https://ghc.haskell.org/trac/ghc/ticket/15124#ticket where I tracked some of the issues I ran into. As it stands some cmm optimizations are far out weighted by accidental changes they cause in the layout of basic blocks. The main problem seems to be that the current codegen only considers the last jump in a basic block as relevant for code layout. This works well for linear chains of control flow but behaves badly and somewhat unpredictable when dealing with branch heavy code where blocks have more than one successor or calls. In particular if we have a loop A jmp B call C call D which we enter into at block B from Block E we would like something like: E,B,C,D,A Which means with some luck C/D might be still in cache if we return from the call. However we can currently get: E,B,A,X,D,X,C where X are other unrelated blocks. This happens since call edges are invisible to the layout algorithm. It even happens when we have (conditional) jumps from B to C and C to D since these are invisible as well! I came across cases where inverting conditions lead to big performance losses since suddenly block layout got all messed up. (~4% slowdown for the worst offenders). So I'm looking for solutions there.

4 5

Use NULL instead of END_X_QUEUE closures?
by Ömer Sinan Ağacan 08 May '18

08 May '18

Currently we sometimes use special closures to mark end of lists of different objects. Some examples: - END_TSO_QUEUE - END_STM_WATCH_QUEUE - END_STM_CHUNK_LIST But we also use NULL for the same thing, e.g. in weak pointer lists (old_weak_ptr_list, weak_ptr_list). I'm wondering why we need special marker objects (which are actual closures with info tables) instead of using NULL consistently. Current approach causes a minor problem when working on the RTS because every time I traverse a list I need to remember how the list is terminated (e.g. NULL when traversing weak pointer lists, END_TSO_QUEUE when traversing TSO lists). Ömer

2 1

Fwd: Availability of Coercible Instances at TH Runtime
by Travis Whitaker 07 May '18

07 May '18

Given that Coercible instances are Deeply Magical, perhaps I'm being a bit naive here, but I recently tried to write a TH function that can check if one type is a newtype of another (or a newtype of a newtype of another, etc). coercibleToFrom :: Type -> Type -> Q Bool coercibleToFrom tx ty = (&&) <$> isInstance ''Coercible [tx, ty] <*> isInstance ''Coercible [ty, tx] If this worked as I'd hoped, I'm almost certain checking reflexively is redundant. However, I can't seem to get reifyInstances to ever return an InstanceDec for a Coercible instance. Given that these instances are generated on the fly by the typechecker, there's no way to make them available at TH runtime, correct? And, given that, is there an easy way to find out with TH whether not I'll be able to use coerce without taking all the Decs apart to hunt for NewtypeD? Travis

4 6

potential for GHC benchmarks w.r.t. optimisations being incorrect
by Daniel Cartwright 07 May '18

07 May '18

I am admittedly unsure of how GHC's optimisation benchmarks are currently implemented/carried out, but I feel as though this paper and its findings could be relevant to GHC devs: http://cis.upenn.edu/~cis501/papers/producing-wrong-data.pdf Basically, according to this paper, the cache effects of changing where the stack starts based on the number of environment variables are huge for many compiler benchmarks, and adjusting for this effect shows that gcc -O3 is only in actuality 1% faster than gcc -O2. Some further thoughts, per http://aftermath.rocks/2016/04/11/wrong_data/ : "The question they looked at was the following: does the compiler’s -O3 optimization flag result in speedups over -O2? This question is investigated in the light of measurement biases caused by two sources: Unix environment size, and linking order. to the total size of the representation of Unix environment variables (such as PATH, HOME, etc.). Typically, these variables are part of the memory image of each process. The call stack begins where the environment ends. This gives rise to the following hypothesis: changing the sizes of (unused!) environment variables can change the alignment of variables on the stack and thus the performance of the program under test due to different behavior of hardware buffers such as caches or TLBs. (This is the source of the hypothetical example in the first paragraph, which I made up. On the machine where I am typing this, my user name appears in 12 of the environment variables that are set by default. All other things being equal, another user with a user name of a different length will have an environment size that differs by a multiple of 12 bytes.)" "So does this hypothesis hold? Yes. Using a simple computational kernel the authors observe that changing the size of the environment can often cause a slowdown of 33% and, in one particular case, by 300%. On larger benchmarks the effects are less pronounced but still present. Using the C programs from the standard SPEC CPU2006 benchmark suite, the effects of -O2 and -O3 optimizations were compared across a wide range of environment sizes. For several of the programs a wide range of variations was observed, and the results often included both positive and negative observations. The effects were not correlated with the environment size. All this means that for some benchmarks, a compiler engineer might by accident test a purported optimization in a lucky environment and observe a 10% speedup, while users of the same optimization in an unlucky environment may have a 10% slowdown on the same workload." I write this out of curiosity, as well as concern, over how this may affect GHC.

4 4

Phabricator upgraded
by Ben Gamari 03 May '18

03 May '18

Hi everyone, I just finished performing a bit of wor on Phabricator. In addition to doing a small upgrade, I disabled the draft state that newly-submitted differentials were previously ending up in. Hopefully this will restore sanity to the code review process. Cheers, - Ben

1 0

Question about ArrayArray#
by Michal Terepeta 03 May '18

03 May '18

Hi all, I have a quick question about ArrayArray#. Is it safe to store *both* an ByteArray# and ArrayArray# within the *same* ArrayArray#? For instance: - at index 0 of an ArrayArray# I store a different ArrayArray#, - at index 1 of that same ArrayArray# I store a ByteArray#. It seems to me that this should be safe/supported from the point of view of the runtime system: - both ArrayArray# and ByteArray# have the same kind/runtime representation, - the arrays have a header that tells rts/GC what they are/how to handle them. (But I, as a user, would be responsible for using the right primop with the right index to read them back) Is this correct? Thanks a lot! - Michal

2 2

ghc 8.4.1 and trac 13930
by Evan Laforge 02 May '18

02 May '18

I recently noticed that with -O1, ghc was optimizing some code if Trace.traceShowId "b" $ True then return $ Left $ Serialize.BadMagic (Serialize.magicBytes magic) file_magic else first Serialize.UnserializeError <$> Exception.evaluate (Serialize.decode rest) to always evaluate the 'else' branch. This is fixed in 8.4.2, so I'm pretty sure it's https://ghc.haskell.org/trac/ghc/ticket/13930 I assume there's no point trying to get a minimal reproduction, since it's a known issue and fixed. Still, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… says "incorrectly optimised, resulting in space leaks". Maybe it should instead say "incorrectly optimised, resulting in taking the wrong branch in 'if' expressions"? That's a bit more alarming, and is a stronger "upgrade to 8.4.2" signal.

3 7

building ghc once or twice?
by Jens Petersen 02 May '18

02 May '18

I have been packaging ghc for a long time... In older times I think it was recommended to first do a (quick) build of a new version of ghc (with the previous version) and then to do a (perf) rebuild of the new version against itself. In fact I am still building ghc this way for Fedora: though it seems like this is overhead nowadays...? (I think one major reason was to get stable ABI hashes for the core library packages.) These days should I just do a single default or perf build of a new ghc version against a previous stable release, or does it still make sense to continue to build in two steps like I have been doing? Any pros or cons? Jens

2 1

RE: Open up the issues tracker on ghc-proposals
by Simon Peyton Jones 02 May '18

02 May '18

| > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. The Right Thing is surely for the main GHC proposals pave https://github.com/ghc-proposals/ghc-proposals to describe how you can up a "pre-proposal". That is, document the entire process in one, easy to find, place. Mind you, I'm unclear about the distinction between a pre-proposal and a proposal. Both are drafts that invite community discussion, prior to submitting to the committee for decision. Simon | -----Original Message----- | From: Glasgow-haskell-users <glasgow-haskell-users- | bounces(a)haskell.org> On Behalf Of Anthony Clayden | Sent: 02 May 2018 02:34 | To: glasgow-haskell-users(a)haskell.org; ghc-devs(a)haskell.org | Subject: Re: Open up the issues tracker on ghc-proposals | | > On May 1, 2018, at 2:24 PM, David Feuer <david.feuer at | gmail.com> wrote: | > | > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. | | As a datapoint, I found ghc-users and the café just fine for those | discussions. | Ghc-users seems to have very low traffic/is rather wasted currently. | And I believe a lot of people pre-discuss on reddit. | For ideas that have been on the back burner for a long time, there's | often wiki pages. (For example re Quantified | Constraints.) | | > I'd like to propose that we open up the GitHub issues | tracker for ghc-proposals to serve as a place to discuss pre-proposal | ideas. Once those discussions converge on one or a few specific plans, | someone can write a proper proposal. | | I'm not against that. There gets to be a lot of cruft on some | discussions about proposals, so I'd expect we could archive it all | once a proposal is more formalised. | | AntC | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0