- ghc-devs - Haskell.org

suboptimal ghc code generation in IO vs equivalent pure code case
by Harendra Kumar 09 May '16

09 May '16

I have a loop which runs millions of times. For some reason I have to run it in the IO monad. I noticed that when I convert the code from pure to IO monad the generated assembly code in essence is almost identical except one difference where it puts a piece of code in a separate block which is making a huge difference in performance (4-6x slower). I want to understand what makes GHC to generate code in this way and if there is anything that can be done at source level (or ghc option) to control that. The pure code looks like this: decomposeChars :: [Char] -> [Char] decomposeChars [] = [] decomposeChars [x] = case NFD.isDecomposable x of True -> decomposeChars (NFD.decomposeChar x) False -> [x] decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs The equivalent IO code is this: decomposeStrIO :: [Char] -> IO [Char] decomposeStrPtr !p = decomposeStrIO where decomposeStrIO [] = return [] decomposeStrIO [x] = do res <- NFD.isDecomposable p x case res of True -> decomposeStrIO (NFD.decomposeChar x) False -> return [x] decomposeStrIO (x : xs) = do s1 <- decomposeStrIO [x] s2 <- decomposeStrIO xs return (s1 ++ s2) The difference is in how the code corresponding to the call to the (++) operation is generated. In the pure case the (++) operation is inline in the main loop: _cn5N: movq $sat_sn2P_info,-48(%r12) movq %rax,-32(%r12) movq %rcx,-24(%r12) movq $:_con_info,-16(%r12) movq 16(%rbp),%rax movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) leaq -48(%r12),%rsi leaq -14(%r12),%r14 addq $40,%rbp jmp GHC.Base.++_info In the IO monad version this code is placed in a separate block and a call is placed in the main loop: the main loop call site: _cn6A: movq $sat_sn3w_info,-24(%r12) movq 8(%rbp),%rax movq %rax,-8(%r12) movq %rbx,(%r12) leaq -24(%r12),%rbx addq $40,%rbp jmp *(%rbp) out of the line block - the code that was in the main loop in the previous case is now moved to this block (see label _cn5s below): sat_sn3w_info: _cn5p: leaq -16(%rbp),%rax cmpq %r15,%rax jb _cn5q _cn5r: addq $24,%r12 cmpq 856(%r13),%r12 ja _cn5t _cn5s: movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) movq 16(%rbx),%rax movq 24(%rbx),%rbx movq $:_con_info,-16(%r12) movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) movq %rbx,%rsi leaq -14(%r12),%r14 addq $-16,%rbp jmp GHC.Base.++_info _cn5t: movq $24,904(%r13) _cn5q: jmp *-16(%r13) Except this difference the rest of the assembly looks pretty similar in both the cases. The corresponding dump-simpl output for the pure case: False -> ++ @ Char (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char)) (Data.Unicode.Internal.Normalization.decompose_$sdecompose ipv_smuv ipv1_smuD); And for the IO monad version: False -> case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) -> (# ipv4_XmXv, ++ @ Char (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char)) ipv5_XmXx #) }; The dump-simpl output is essentially the same except the difference due to the realworld token in the IO case. Why is the generated code different? I will appreciate if someone can throw some light on the reason or can point to the relevant ghc source to look at where this happens. I am using ghc-7.10.3 in native code generation mode (no llvm). Thanks, Harendra

1 0

[Maintainer needed] Actively maintained Haddock are happy Haddock
by Ben Gamari 06 May '16

06 May '16

tl;dr. Our Haddock need a dedicated maintainer responsible for their care and feeding. Would you like to move forward a critical piece of infrastructure used on a daily basis by thousands of Haskellers? Let us know if so. Hello everyone, While for several years Mateusz Kowalczyk and Simon Hengel have done an admirable job in serving as comaintainers of the Haddock documentation tool, they have both indicated that they no longer have the time to continue to be active in this role. They both deserve our thanks for their service. While Matthew Pickering and I have tried to pick up some of the Haddock's maintenance load in the meantime, we really need a dedicated maintainer to ensure that Haddock continues to swim along healthfully. At the moment there are over 150 open tickets in the issue tracker [1], an open call for a stable release, and 4 patches in need of review. We currently lack the time to get on top of such a load. In particular, Haddock need someone to take ownership of the management of the project: this person would keep an eye on (and preferably pare down) the issue tracker (which typically isn't very active, happily), guide new contributors, and manage releases. This is an opportunity to drive forward a project used on a daily basis by a significant fraction of Haskellers. If you think you might be interested in serving in this role, please let us know. Thanks! Cheers, - Ben [1] https://github.com/haskell/haddock/pulls

2 2

pmcheck/T11195
by Simon Peyton Jones 06 May '16

06 May '16

Harbourmaster is failing (“Killed”) on pmcheck/should_compile/T11195. Are others finding this? What should we do? SImon

1 0

Re: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2016 edition (30th edition)
by Ben Gamari 05 May '16

05 May '16

Mihai Maruseac <mihai.maruseac(a)gmail.com> writes: > Hi, > > Thanks for the entry. In the past, I was copying the text at > https://ghc.haskell.org/trac/ghc/wiki/Status/May16 (with the > corresponding different date at the end) and formatting it in LaTeX. > Now I got a tex file which looks exactly like the text in the Trac > wiki. If not mentioned otherwise, I guess I'll use the .tex file, > since it will be easier. > Ahh, I see; thanks for letting me know! I think this time around it would be better you use the TeX source I provided as I made a few formatting improvements over the Trac document. Cheers, - Ben

1 0

Looking for GHC compile-time performance tests
by Ben Gamari 05 May '16

05 May '16

tl;dr. Do you have a Haskell project which GHC now compiles more slowly than in the past? If you would like to see your program's compilation time improve in 8.2, reduce it to a minimal testcase, and provide it to us via Trac. Good news everyone, GHC 8.2 will be a release largely targetting consolidation instead of new features. In particular, we will focus on compiler performance issues. One of the challenges of this task is knowing in which ways GHC has regressed. It is currently hard to know how much of the apparent compiler performance regression is due to GHC getting slower and how much is due to users demanding more of it. To better understand the performance of our compiler, we would like to collect modern Haskell code samples that exhibit compile-time performance issues (either regressions or otherwise). For this we are asking for your help: we are looking for projects that, * are small-to-moderate-sized Haskell programs which you believe have regressed in compile time in the last few GHC releases * have minimal build dependencies, in the ideal case none outside of the standard GHC boot libraries * can be licensed for use under 3-clause BSD In some cases we may also be able to make use of examples with a few library dependencies that are necessary to demonstrate the performance issue (for instance, a suspected issue stemming from stream fusion requiring Conduit). For performance issues exhibiting non-linear scaling in some quantity (e.g. the size of a type in the program), it would be extremely helpful if the testcase exposed a "knob" demonstrating this scaling. So, if you would like to see your program's compilation time improve in GHC 8.2, put some time into reducing it to something minimal, submit it to us via a Trac ticket, and let us know in this thread. Thanks for your help! Cheers, - Ben

1 0

[Action Needed] Document your work for the Haskell Communities and Activities Report
by Ben Gamari 05 May '16

05 May '16

TL;DR. If you see your name in one of the two lists below, please edit the entries for your contributions to 8.0 and plans for 8.2 in the 2016 GHC HCAR report [1]. The deadline is in a few short weeks so act soon! Hello GHC people, As you might know, it's that time of the year where we have an opportunity to reflect on the past and future strides taken by our glorious compiler in GHC's Haskell Communities and Activities Report submission [1]. We have had lots of great work go in to the imminent 8.0.1 release; let's make sure the community knows about it. Currently listed is, Adam Gundry Record system improvements Adam Sandberg Eriksson Strict pragma Duncan Coutts Environment files? Edward Z. Yang Backpack improvements Eric Seidel Implicit callstacks Eric de Casto Lopo ARM support George Karachalias Pattern match checker rewrite Herbert V. Riedel AIX support Jan Stolarek Injective type families Richard Eisenberg Visible type application, kind equalities Ryan Scott Improved Generics, DerivingLift Sergei Trofimovich Portability Simon Marlow Applicative do syntax, external GHCi Tamar Christina Windows improvements While Austin and I have done our best to stub out these entries, we need your help to fill in the details. If you see your name in this list please look at the current draft [1] and add what you can. Also, if you see anything missing from this list please let us know or, better yet, add an entry to the submission yourself. Also, if you are planning on including any major changes in the 8.2 release, please add an entry to the "upcoming plans" section. As far as I know at very least the following people should have interesting things to share, Andrew Farmer Profiler improvements Andrey Mokhov Shake build system Austin Seipp LLVM backend Bartosz Nikita Deterministic compilation Core Libs Committee Core libraries changes Edward Yang Backpack, Compact regions Giovanni Campagna Compact regions Simon Marlow Various things I'm sure Ömer Sinan Ağacan Unboxed sums, unpacking sum types Again, if you know of someone not on this list who is considering contributing to 8.2 please have them add their item to the report. If there is any way that Austin or I can help don't hesitate to reach out. Thanks for your contributions over the last year! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/May16

1 1

Re: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2016 edition (30th edition)
by Ben Gamari 05 May '16

05 May '16

Ben Gamari <ben(a)well-typed.com> writes: > [ Unknown signature status ] > Mihai Maruseac <mihai.maruseac(a)gmail.com> writes: > >> Dear all, >> >> It's that time of the year again (https://ro-che.info/ccc/16) :) >> >> We would like to collect contributions for the 30th edition of the >> > Hello Mihai, > > Here is GHC's contribution to the current HCAR. Let me know if you'd > like me to make any revisions. Sorry for the late submission! > Hi Mihai, If possible, it would be great if you could instead use this revised HCAR text as GHC's submission. This includes a few late amendments that would be nice to have. Cheers, - Ben

1 0

Generics performance
by Ben Gamari 05 May '16

05 May '16

Hi Ryan! As you may know, we are encouraging contributors to view the 8.2 release as a consolidation release, using it as an opportunity to optimize, stabilize, document, and refine existing features instead of introducing new ones. It seems like there is plenty of optimization that could be done in your area of generics. In particular #5642 and #11991 are quite relevant and have been felt by a fair number of users. While compiling derived Generic instances can necessarily produce quadratic code (see ticket:5642#comment:8), the costs that we are seeing do seem a bit high so perhaps there are some constant factors that we can knock down. However, working this out will require a concerted effort. Would you be interested in picking up this issue as a task for 8.2? Cheers, - Ben

1 0

Draft 8.0 Mac build directions
by Carter Schonwald 04 May '16

04 May '16

Hey all: I've drafted some hopefully cleaner Mac build directions and I'd love some feedback on them Nb: I think I forgot to mention the cabal install hscolour step, I'll add that -Carter

5 9

Bikeshedding request for GHCi's :type
by Richard Eisenberg 03 May '16

03 May '16

Hi devs, Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963) which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963. Thanks! Richard

7 7