- ghc-devs - Haskell.org

Unique invariants: GHC invocation vs scope?
by Csaba Hruska 09 May '20

09 May '20

Hello, What are the intended invariants of Unique values? So far I thought that it is always gives a unique identity to things during a whole GHC invocation. However this is not true. I.e. eta expansion breaks this assumption. Here is a snippet from the STG IR of GHC.PrimopWrappers: extendInt8# [InlPrag=NOINLINE] :: Int8# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] extendInt8# [eta_B1]; ord# [InlPrag=NOINLINE] :: Char# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] ord# [eta_B1]; Where eta_B1 is redefined, so it is only unique in the scope. Is this intentional? Thanks, Csaba Hruska

2 1

[RFC] Compiler pipeline timings visualization
by Sergej Jaskiewicz 06 May '20

06 May '20

tl;dr: I propose adding a new GHC flag for generating a log that allows visualizing how much time each stage in the compiler pipleline took, similar to Clang's -ftime-trace. Hello, everyone. I'd like to tell you about a feature I've been working on recently, namely, the ability to generate and visualize how long each stage of the compilation pipeline takes to complete. This is basically about the same as the -ftime-trace flag that has landed in Clang several months ago [1]. The initial motivation for this feature was the desire to understand why compilation times are so long when using LLVM as backend. But later I realized that this functionality is useful on its own for end users, not just GHC devs, so it would make sense to add a new flag -ddump-time-trace. Since not only does Haskell have complex type system, but also there is a variety of language extensions, we, the Haskell users, often experience very long compilation times. For instance, the usage of the TypeFaimilies extension can considerably slow down the compilation process [2]. It is useful to understand how you can fix your code so that it compiles faster. There are two options for that right now: - Building GHC from source for profiling and using the just-built GHC for compiling your problem code. - Building the compiler from source with event log support [3]. The former option just doesn't do it, since the output would be "which GHC function calls took how much time", but there'd be no information about which part of the user code was being compiled. The latter option is much closer to what we need. If we link the GHC executable with the -eventlog flag, then various significant events will be written to a special log file. For example, "Parser began parsing the Main.hs file after 5 ms since GHC has started, and ended parsing it 3 ms after that". The resulting log file can be parsed with the ghc-events library [4], and also visualized using the ThreadScope app [5]. Bu this approach has its disadvantages. Firstly, if the user wants visualization, they'd have to install ThreadScope. Some companies' internal policies prohibit installing third-party apps from the internet. It would be good if we could generate a log that could be visualized on any computer with a browser. For that we could use the Chrome Trace Event format [6]. This is an ordinary JSON file with a specific structure that can be viewed in the Chrome browser by going to the chrome://tracing page, or on https://speedscope.app. A file in exactly this format would be generated by Clang if you passed it the -ftime-trace flag. Secondly, the event log contains many events that are not relevant to the end user, for example, thread creation, memory allocation, etc. As an initial proof of concept, I've developed a command line tool for transforming event log files to Chrome Trace Event files [7]. Thirdly, in order for the event log to be generated, you'd still have to build GHC from source. The majority of the GHC users won't go this way. Not only would it require some basic understanding of the GHC building process, but also building itself takes quite some time. It would be great if the needed functionality came with GHC out of the box. This is why I've added support for generating Trace Event files into my fork of GHC [8], and I would like to propose including this feature into the mainline GHC. (Note that my implementation is still a bit buggy, for example, it only works in -j mode. This will be fixed.) You can now execute the following command: ghc -ddump-to-file -ddump-file-prefix="Main." -ddump-time-trace -j -O3 Main.hs And receive this image [9]. Here, we've compiled two modules, one of which depends on the other. One more difference from event log is that now various metadata (like file and module names) are emitted as a separate JSON attribute, instead of being encoded in the name of an event. For example, parsing the Main.hs file and parsing the QSort.hs file in one compilation are events with the same name, but different metadata. We can group them together if we want to know how much time the parsing took overall. The event log format doesn't allow us to do it. So, we can now generate a Trace Event file from a single GHC invocation. However, most projects use build systems that invoke the compiler many times. It would be good if we could form a log for the whole project. This is solved by merging logs. However, there is one subtlety: the events in logs use relative timestamps (the number of microseconds since the process has started). To combine logs from multiple processes, we add a clock synchronization point into each trace log in the form of an additional 'beginningOfTime' JSON attribute that contains the absolute time when the proccess has started. There is a Python script that performs the actual merging [10]. This is how it looks like with multiple processes [11]. Also, I've implemented generation of the 'beginningOfTime' attribute in LLVM [12], so build systems could take advantage of that and combine GHC trace logs with llc/opt trace logs when GHC uses LLVM as backend. Thoughts? Sergej. [1] https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profile… [2] https://gitlab.haskell.org/ghc/ghc/issues/8095 [3] https://gitlab.haskell.org/ghc/ghc/-/wikis/event-log [4] http://hackage.haskell.org/package/ghc-events [5] https://wiki.haskell.org/ThreadScope [6] https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchN… [7] https://github.com/broadwaylamb/ghc-eventlog-chrome [8] https://gitlab.haskell.org/broadwaylamb/ghc/-/commits/timetrace-better-meta… [9] https://user-images.githubusercontent.com/16309982/79079705-39775e00-7d19-1… [10] https://github.com/broadwaylamb/merge_trace_events [11] https://user-images.githubusercontent.com/16309982/79080338-ad673580-7d1c-1… [12] https://github.com/llvm/llvm-project/commit/2899103108d38215af8aae377cd0e54…

7 6

[8.12] Documentation plans
by Hécate 06 May '20

06 May '20

Hello ghc-devs For everyone who doesn't know me (yet), I am Hécate, and I coordinate the the Haskell Docs initiative. You may have seen me on various community channels and on social media to recruit lost souls^W^Wmotivated volunteers to help improve the documentation of the `base` library. It can be a daunting task, hence this page that I set up to guide newcomers and track ongoing work[0] The point of my message is the following: If there are any modules you would like to see prioritised for the next release (8.12), please contact us. Current efforts are very organic and stem from personal hardships with the docs, but if you feel that some parts of the docs have been left too long on their own, give us a heads-up. If you want to personally take on a module whose documentation you deem lacking, feel free to join us on #Haskell-docs[1] , so we can coordinate and avoid multiple people working at the same time in an uncoordinated manner towards the same goal. And finally if you do not wish to get involved but still wish to support, we communicate on Twitter[2] and the Fediverse[3]. I would like to end this email by thanking Ben and Carter for their support and guidance. The Core Libraries Committee has been instrumental to the development of these efforts. Cheers, and take care. [0]: https://gitlab.haskell.org/ghc/ghc/issues/17929 [1]: https://webchat.freenode.net/ (enter #Haskell-docs in the 'channel' field) [2]: twitter.com/search?q=%23HaskellDocs [3]: https://search.social/?q=%23haskelldocs -- Hécate IRC: Uniaika Twitter: @TechnoEmpress Fediverse: @hecate@pleroma.fr

3 3

Re: Connecting the Wolfram Language to Haskell
by Compl Yue 06 May '20

06 May '20

Hi, If you are already running atop the Jupyter technology stack, IHaskel [1] may be very straight forward to be incorporated from technical aspect (while licensing aspect is out of my expertise). But still I would like take this opportunity to have more/further evaluation from you, about [2] , with by far my implementation [3] and application [4]. Once a frontend plugin can be injected into a GHCi session, and hooked up to some interactive UI, a new door is opened to allow much easier setup & use of GHC API interactively, like demonstrated in Hadui [4]. Currently there are too many different ways to setup a GHC API session, HIE has tried hard to unify them, but itself is yet under transition. I see the frontend interface being a proper abstraction even extended to WebUI/GUI applications, making interactions perfectly decoupled from how the underlying artifacts are organized, thus worth further consideration. While IHaskell is more powerful and better established as with Jupyter notebook, I chose the frontend route because IHaskell didn't come to today's maturity when I needed something like Hadui, and ZeroMQ seems bloating to my cases, even for now. Cheers, Compl [1] https://github.com/gibiansky/IHaskell [2] https://gitlab.haskell.org/ghc/ghc/issues/17348 [3] https://gitlab.haskell.org/complyue/ghc/tree/ghc-8.6-ife [4] https://github.com/complyue/hadui On 2020/5/1 上午5:13, Ben Gamari wrote: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> <ghc-devs(a)haskell.org> writes: Friends Short summary: can someone familiar with using the GHC API offer advice on getting the Wolfram Language connected to Haskell? Hi Todd, et al., This sounds like a great project. I have fond memories of Mathematica from my studies. ... We have the following basic line of code for evaluating a string of Haskell code: r <- liftIO $ runInterpreter $ do { setImports ["Prelude"]; eval strToEvaluate} The problem is that this is a one-shot evaluation, and we want a long-lived interactive Haskell session, to which a series of inputs can be directed. We have been told that we have to use GHCi for that, but we don't know how to do it. It appears that you are using the `hint` library [1] for evaluation. I'll admit that I've not used hint; it looks quite sensible but I do not know what limitations you might encounter. It looks like its approach to error handling may leave something to be desired. Nevertheless, we can work with it for now; if we run into its limitations then the alternative is to use the GHC API directly, as suggested by Simon. The basic flow of our functionality is as follows: 1) User calls StartExternalSession["LanguageName"] to launch an interpreter for the language. This process remains running and can be used for multiple calls. 2) User calls ExternalEvaluate[session, "some code"] to execute the given code in the external language and return a result converted into native Wolfram Language types (strings, numbers, lists, associations, etc.) Sure. ... We have attached a simple file of Haskell code that one of our engineers has successfully used to get a basic evaluation of Haskell code from the Wolfram Language, but it uses the single-shot evaluation code that was given above, and so is not suitable. We would appreciate any help that you can give us, or developers or resources you can point us at, to assist in integrating Haskell into our ExternalEvaluate system. It looks like you will want to push the `runInterpreter` out of the `forever`. Afterall, you want the interpreter session to persist over multiple requests. Doing this isn't difficult but does require some monad transformer shuffling, which may be unfamiliar to someone coming from another language. I've put up a cleaned up version of your program here [1]; hopefully this is enough to get you started. Do note that this requires a patched version of zeromq4-haskell due to a minor bug [2] which I have fixed [3]. Do note that there is a related effort, iHaskell [4], which provides a Haskell kernel for Jupyter Notebook. This might be a place to draw inspiration from. Let us know how things go and don't hesitate to be in touch if you have questions regarding the GHC API. Cheers, - Ben [1] https://github.com/bgamari/zeromq-hint [2] https://gitlab.com/twittner/zeromq-haskell/-/issues/66 [3] https://gitlab.com/twittner/zeromq-haskell/-/merge_requests/6 [4] https://github.com/gibiansky/IHaskell _______________________________________________ ghc-devs mailing listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Expanding a particular type family in type errors
by Alexis King 06 May '20

06 May '20

Hi all, As part of my ongoing rework of arrow notation <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3191>, I have introduced two wired-in type families, which assist in the typechecking process. The details are not terribly important (you can read the proposal if you’d like for those), but the relevant detail is that equalities of the shape ArrowStackTup a ~ b are produced by the typechecker in key places. ArrowStackTup is one of my wired-in type families, and it’s really an implementation detail. Unfortunately, I often end up with type errors that leak this detail, with expected/actual types like these ones: Expected type: ArrowStackTup '[Int] -> Bool Actual type: Int -> String This is quite annoying, as it’s exceedingly rare that these type families actually get stuck, so they can almost always be expanded in type errors. As it happens, `ArrowStackTup '[a]` expands to simply `a`, so the type error I would like to report is this one: Expected type: Int -> Bool Actual type: Int -> String Not technically challenging, but I find myself faced with the question of where this special expansion logic ought to go. It seems like it could go in any of several places: It could be hard-wired into pprType, and perhaps selectively disabled with an -fprint-* flag. This is nice in that it’s universal, but it’s almost certainly a step too far: the casts for ArrowStackTup still end up in Core, and expanding the type synonyms there would be quite confusing. The expansion could happen in tidyType, since it’s called before reporting an error. But this seems probably even worse than putting it in pprType, since it’s still used in too many places, and it isn’t supposed to actually change the type. It could be handled as an extra, ad-hoc preprocessing step in reportWanteds. This is much closer to reasonable, though it feels like quite a hack. A separate error Reporter could catch these errors before the other reporters do and perform the expansion there. But I don’t think this actually makes sense, as the above example demonstrates that ArrowStackTup might be buried inside another type and in fact might not actually be the source of the type error at all! It could be done last-minute in mkEqErr. But I don’t know if this is too late, and ArrowStackTup could leak into an error through some other code path. Of those options, the best one I’ve come up with seems to be option 3, an ad-hoc preprocessing step in reportWanteds. Does that seem reasonable? Or is it too much of a kludge? Thanks, Alexis

2 5

ZuriHac 2020 - GHC Track - Call for Contributions
by Andreas Herrmann 05 May '20

05 May '20

Dear GHC developers, As you may have heard this year's ZuriHac will be an online event due to COVID-19 [1]. Nonetheless, we would like to organize a GHC track again this year with the goal to foster contributions to GHC and teach newcomers how to participate in GHC's development. To that end we would like to invite you to hold seminars, workshops, or hack sessions on topics centered around GHC. Please let us know by replying to this email if you would like to contribute to this year's GHC track. ZuriHac will take place from Friday 12 June to Sunday 14 June. We are still working out the technical details. However, we are planning to provide a virtual space for people to collaborate on projects, participate in voice/video chats, and live stream talks. Best, Andreas [1]: https://zfoh.ch/zurihac2020

1 0

Preview of new profiling mode - profile by info table
by Matthew Pickering 03 May '20

03 May '20

Hi all, I have hacked together a new profiling mode code named "Profile by Info Table" which uses the address of the info table as the band identity in the profile. The main point of this is that you can then look up the source location of the info table in the dwarf information when rendering the chart. For example, in this profile I have only included THUNK closures, which you can reliably look up in the dwarf information. You can't include things like constructor closures for example as every constructor has the same info table regardless of where it comes from in the source. In the profiles below if you click on the Closure Descs tab you can see the precise source position the band originated from. As a test, I compiled the Cabal library with -O2 and here is the result. Firstly a profile sorted by size of the bands. https://mpickering.github.io/ghc-hi-cabal-o2.eventlog.html I also added a mode to eventlog2html which calculates the gradient of the line so you can more easily spot things which are leaking but not very big themselves which might be retaining other closures. https://mpickering.github.io/ghc-hi-cabal-o2-gradient.eventlog.html We can see clearly here that there are calls to compute unfoldings which remain unevaluated for a long time and therefore retaining reference to core expressions. (See the 0x177ff78 closure for example). The only issue is that at the moment reading the DWARF information takes about 48gb of memory. Cheers, Matt

1 0

Hadrian build with DWARF information doesn't contain as much debug information as I would expect
by Matthew Pickering 03 May '20

03 May '20

I followed the instructions on the wiki to enable debug symbols in my build of GHC. (https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#enabling-dwarf-…) So I added these flags to may hadrian.settings file stage1.*.ghc.hs.opts += -g3 stage1.*.cabal.configure.opts += --disable-library-stripping --disable-executable-stripping stage1.ghc-bin.ghc.link.opts += -eventlog The resulting executable has debug information in it for the executable component but not for any of the libraries in including the compiler library. ("../sysdeps/x86_64/start.S",Just 4414944,Just 4414987,139633489318136) ("init.c",Nothing,Nothing,139633489318136) ("../sysdeps/x86_64/crti.S",Nothing,Nothing,139633489318136) ("ghc/Main.hs",Just 4415312,Just 4615455,139633489318136) ("ghc/GHCi/Leak.hs",Just 4615480,Just 4623414,139633489318136) ("ghc/GHCi/UI.hs",Just 4623440,Just 5461990,139633489318136) ("ghc/GHCi/UI/Info.hs",Just 5461992,Just 5571230,139633489318136) ("ghc/GHCi/UI/Monad.hs",Just 5571232,Just 5679695,139633489318136) ("ghc/GHCi/UI/Tags.hs",Just 5679696,Just 5704775,139633489318136) ("ghc/GHCi/Util.hs",Just 24,Just 173,139633489318136) ("../sysdeps/x86_64/crtn.S",Nothing,Nothing,139633489318136) I tried building a project with cabal and the resulting executable had debug information for every file in the dependencies as well as the main project. So how do I convince hadrian to include the correct information? Is it a bug in hadrian? I checked the command line when building the library and `-g3` is passed. Cheers, Matt

3 3

Justifying sched_yield() in the RTS
by Travis Whitaker 02 May '20

02 May '20

Hello GHC devs, Through the course of reading some recent material posted by Linus Torvalds ^1 ^2, I remembered stumbling upon GHC Trac #3553 ^3 some years ago. Looking past the harsh tone Linus used in his notes, I think he makes some pretty reasonable points about the problems that can be caused by using spinlocks in userspace. Specifically: - A group of threads yielding while waiting for a spinlock are, in effect, simply trying to coax the scheduler into scheduling the thread that is holding the lock. This is much easier for the scheduler to do correctly with a futex or similar, since the scheduler has some context around which tasks are blocking/waking each other up. - Apparently the Linux scheduler (and maybe other schedulers) has some smarts for preserving cache locality while choosing which physical execution units run which tasks, and reordering threads in the run list in an ad-hoc way with sched_yield() interferes with this mechanism. - Using sched_yield() (or other random interference with run lists) can cause disproportionate havoc on NUMA systems, where jostling around the lock-holding thread by burning time slices and yielding is especially costly. All that said, there is perhaps one concrete advantage (aside from absolute performance) to the current spinlock implementation: the only functionality it requires from the host OS is a yield-like operation. A yielding spinlock occupies a comfortable local optimum, achieving decent performance across platforms with minimal exposure to cross-OS API differences. Revisiting #3553, it seems the only reason that a futex was not used in place of a spinlock with sched_yield() was that, despite all of the points against it, the spinlock code empirically performed better. However, these tests were performed years ago and the futex implementation in the Linux kernel has changed quite a bit. I think there is a healthy amount of empirical evidence from the GHC user community that there are problems afoot with the way parallel GC does locking, and indeed I wonder if the bad cases Linus described are playing a role. Advice like "use -qg" or "use -qnM with small M" is often parroted (this Twitter thread ^4 contains both pieces of advice). Furthermore, I would wager that an RTS using futexes for locking rather than spinning plays nicer with other CPU intensive tasks on the same machine. The "scheduler storm" caused by a large number of threads waiting for a spinlock could have a negative impact on neighboring processes, e.g. a large number of HECs spinning certainly don't do any favors for a busy neighboring DB process. I'm curious if others have thoughts on reviving the futex investigation. Perhaps the futexes provided by modern Linux are more competitive with the current spinlock implementation, or perhaps better scaling on machines with high core counts is worth some cost. In the case that futexes remain handily defeated by yielding spinlocks, it's a worthy endeavor to explain precisely _why_ this happens. Other programs have seen performance issues crop up when the kernel makes subtle changes to how sched_yield() works. ^5 1: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 2: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189752 3: https://gitlab.haskell.org/ghc/ghc/issues/3553 4: https://twitter.com/ndm_haskell/status/1076187051610042368?s=20 5: https://lwn.net/Articles/31462/

3 3

git prune?
by Simon Peyton Jones 02 May '20

02 May '20

I'm getting lots of the messages below. Running 'git prune' makes no difference. Simon simonpj@MSRC-3645512:~/code/HEAD-5/testsuite/tests/th$ git push --set-upstream origin wip/T18121 Counting objects: 13, done. Delta compression using up to 20 threads. Compressing objects: 100% (13/13), done. Writing objects: 100% (13/13), 1.64 KiB | 418.00 KiB/s, done. Total 13 (delta 11), reused 0 (delta 0) remote: remote: To create a merge request for wip/T18121, visit: remote: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/new?merge_request%5Bsou… remote: remote: warning: The last gc run reported the following. Please correct the root cause remote: and remove gc.log. remote: Automatic cleanup will not be performed until the file is removed. remote: remote: warning: There are too many unreachable loose objects; run 'git prune' to remove them. remote:

2 1