May 2018 - ghc-devs - Haskell.org

Phabricator reboot
by Ben Gamari 17 May '18

17 May '18

Hi everyone, Due to some strange behavior from our Phabricator instance over the last few days I'm going to be bringing it down for a quick reboot in about 30 minutes. The downtime should only be a couple of minutes long. Cheers, - Ben

1 0

HIE Files
by Zubin Duggal 15 May '18

15 May '18

Hello, I will be working on a GSOC project that will allow GHC to output a new .hie file to be written next to .hi files. It will contain information about the typechecked Haskell AST, allowing tooling(like haddocks --hyperlinked-source and haskell-ide-engine) to work without having to parse, rename and typecheck files all over again. I have made a GHC wiki page containing more details here: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles Looking forward to any comments and suggestions. Thanks, Zubin.

4 6

How does the IO manager handle reading regular files?
by Niklas Hambüchen 14 May '18

14 May '18

I just got reminded that epoll() has no effect on regular files on Linux by reading an nginx article [1] [2] and why that is [3] [4]. By what means does the IO manager make reads (wraps around the read() syscall on Linux) non-blocking? Does it always use read() in `foreign import safe` (or `interruptible`) so that an OS thread is spawned? It would be great if somebody could point me to the code where that's done (not again: for *regular* files). Thanks! Niklas [1]: https://www.nginx.com/blog/thread-pools-boost-performance-9x/ [2]: https://stackoverflow.com/questions/8057892/epoll-on-regular-files [3]: https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/ [4]: https://groups.google.com/forum/#!topic/comp.os.linux.development.system/K-…

2 4

Motivation for refineDefaultAlt
by Matthew Pickering 11 May '18

11 May '18

Hi all, Does anyone know the motivation for refineDefaultAlt? The comment states - -- | Refine the default alternative to a 'DataAlt', if there is a unique way to do so. OK - so the code transforms something like case x of { DEFAULT -> e } ===> case x of { Foo a1 a2 a3 -> e } but why is this necessary or desirable? Perhaps you know Simon (Jakobi)? Cheers, Matt

3 3

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 07 May '18

07 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