- ghc-devs - Haskell.org

making ./validate run tests on all CPUs by default
by Sergei Trofimovich 13 Aug '14

13 Aug '14

Good evening all! Currently when being ran './validate' script (without any parameters): - builds ghc using 2 parallel jobs - runs testsuite using 2 parallel jobs I propose to change the default value to amount of available CPUs: - build ghc using N+1 parallel jobs - run testsuite using N+1 parallel jobs Pros: - first-time users will get faster ./validate - seasoned users will need less tweaking for buildbots Cons: - for imbalanced boxes (32 cores, 8GB RAM) it might be quite painful to drag box out of swap What do you think about it? Actual patch: https://phabricator.haskell.org/D146 Thanks! -- Sergei

2 2

Grumpy harbormaster
by Ben Gamari 13 Aug '14

13 Aug '14

I submitted two unrelated differentials today, D152 and D150. Somehow the Harbormaster builds of both have failed in the same peculiar way, silently dying apparently after right after finishing the initial ghc-cabal build. It's entirely possible I'm missing something silly here, but neither of the patches touch anything near Cabal or the build system so I'm a bit perplexed. What to do from here? Cheers, - Ben

1 0

CPP usage in GHC.
by Karel Gardas 12 Aug '14

12 Aug '14

Folks, in my attempt to lower number of failing tests on Solaris I've found several tests which fail on just difference in file name report. My ghc reports warning/error in /tmp/ghc<something>/<some different thing> while expected is clear T<something>.hs. See http://haskell.inf.elte.hu/builders/solaris-x86-head/125/21.html and search for T7145b as an example of this behavior. The reason why this happen is that Solaris GNU C 4.x does not emit line markers in preprocessed file when it's preprocessed with -x assembler-with-cpp. The reason behind this is documented in this thread[1] on GCC mailing list. Simply speaking Sun's assembler in the past chokes on some linemarkers generated. This was apparently case of as on older Solaris then 10 version and perhaps this will be fixed in future major GCC release as Solaris 9 is not supported anymore. Anyway, we still do have a case with GNU C compilers provided by Solaris 10 and Solaris 11. FYI: Solaris' 10 GNU C 3.4.x is OK, Solaris 11's GNU C 4.5.2 is broken and with this all more modern 4.x releases so probably also all 4.x release provided by Solaris 11.1/11.2. So far I've solved the issue of those failing tests by passing --with-hs-cpp=/usr/sfw/bin/gcc -- so configured this way GHC will use old not-buggy GNU C 3.4.x on my Solaris 11 builder as CPP and otherwise it'll use /usr/bin/gcc (GNU C 4.5.2) and everything will pass fine hopefully. Anyway, the thread[1] also contains a question which also rings in my head and that is: why we use -x assembler-with-cpp at all? Isn't simple -E enough. Or isn't simple usage of system provided CPP enough /usr/lib/cpp on Solaris)? Or what will happen if we for example change -x assembler-with-cpp to -x c or -x c-header or something like that? Please note that the testcase is OK with -x c/c-header even using this "buggy" GNU C 4.5.2 since the compiler/cpp is really buggy just for the case of -x assembler-with-cpp. Thanks! Karel [1]: https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

2 9

diff'ing in Diffusion
by Richard Eisenberg 12 Aug '14

12 Aug '14

Hi all, I wanted to see a side-by-side diff of the GHC code between 7.8.2 and 7.8.3. So, I went to Phab's Diffusion application. I can access the different commits I wish to compare, but I can't seem to find a "Compare" or "Diff" button. Any hints? Thanks! Richard

1 0

Re: Overlapping and incoherent and intentionally omitted instances
by Iavor Diatchki 10 Aug '14

10 Aug '14

Hello, Such a pragma sounds useful, and is very much like the "fails" instance from the "Instance chains" paper. You may also be interested in ticket #9334 (https://ghc.haskell.org/trac/ghc/ticket/9334) which proposes an alternative to overlapping instances, and I just updated it to point to #7775. -Iavor On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann < schlepptop(a)henning-thielemann.de> wrote: > Am 29.07.2014 um 12:02 schrieb Johan Tibell: > > P.S. For e.g. INLINABLE we require that you mention the function name >> next to the pragma (which means that you can e.g. put the pragma after >> the declaration). What's the rationale to not require >> >> {-# OVERLAPPING Show [Char] #-} >> >> here? Perhaps it's too annoying to have to repeat the types? >> > > Once I proposed a pragma for documenting intentionally unimplemented > instances. In this case there is no instance you can write a pragma in > front of. Your OVERLAPPING syntax would be conform with the one of > NOINSTANCE: > > https://ghc.haskell.org/trac/ghc/ticket/7775 > > Maybe NOINSTANCE can be reconsidered in the course of the introduction of > the OVERLAP pragma? > >

1 0

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Sergei Trofimovich 10 Aug '14

10 Aug '14

On Wed, 6 Aug 2014 22:15:34 +0300 Sergei Trofimovich <slyfox(a)gentoo.org> wrote: > On Wed, 06 Aug 2014 09:30:45 +0200 > Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > > Hi, > > > > the attached commit seems to have regressed the scs nofib benchmark by > > ~3%: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… > > That's a test of compiled binary performance, not the compiler, right? > > > The graph unfortunately is in the wrong order, as the tool gets confused > > by timezones and by commits with identical CommitDate, e.g. due to > > rebasing. This needs to be fixed, I manually verified that the commit > > below is the first that shows the above-noise-level-increase of runtime. > > > > (Other benchmarks seem to be unaffected.) > > > > Is this regression expected and intended or unexpected? Is it fixable? > > Or is is this simply inexplicable? > > The graph looks mysterious (18 ms bump). Bencmark does not use haskell threads at all. > > I'll try to reproduce degradation locally and will investigate. I think I know what happens. According to perf the benchmark spends 34%+ of time in garbage collection ('perf record -- $args'/'perf report'): 27,91% test test [.] evacuate 9,29% test test [.] s9Lz_info 7,46% test test [.] scavenge_block And the whole benchmark runs a tiny bit more than 300ms. It is exactly in line with major GC timer (0.3s). If we run $ time ./test inverter 345 10n 4u 1>/dev/null multiple times there is heavy instability in there (with my patch reverted): real 0m0.319s real 0m0.305s real 0m0.307s real 0m0.373s real 0m0.381s which is +/- 80ms drift! Let's try to kick major GC earlier instead of running right at runtime shutdown time: $ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null real 0m0.304s real 0m0.308s real 0m0.302s real 0m0.304s real 0m0.308s real 0m0.306s real 0m0.305s real 0m0.312s which is way more stable behaviour. Thus my theory is that my changed stepped from "90% of time 1 GC run per run" to "90% of time 2 GC runs per run" -- Sergei

3 3

arc diff linter looping / stuck
by Richard Eisenberg 08 Aug '14

08 Aug '14

Hi all, I've prepared a bunch of commits to fix several tickets. After pushing these commits to branch wip/rae (to save my place and to get validate running on Travis), I then `git checkout`ed back to a point where `git diff origin/master` gave me a patch for precisely one bug (instead of the several unrelated ones I had fixed). I wanted to post to Differential. `arc diff` allowed me to fill out a description message (which mentioned, in its comments, the right set of commits), but then hung on the "linting..." stage. I suppose I could skip the linter, but it's more likely I've done something wrong here... Any advice? In the meantime, please consider this to be a request for feedback on everything in wip/rae! The bugs fixed are #9200, #9415, #9404, and #9371. Thanks! Richard

2 2

biographical profiling is broken?
by Ömer Sinan Ağacan 08 Aug '14

08 Aug '14

Hi all, I'm trying to use LDV profiling features of GHC but I'm failing. Here's what I try: (I'm using GHC 7.8.2) * I'm compiling my app with `-prof` and I'm also using `-fprof-auto` just to be sure. * I'm running my app using `+RTS -hbdrag,void` as described in the docs. (https://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html#bio…) This always generates an empty MyApp.hp file. There's only this header in the generated file: JOB "MyApp +RTS -hd -hbdrag,void,lag" DATE "Thu Aug 7 18:14 2014" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.00 END_SAMPLE 0.00 BEGIN_SAMPLE 0.10 END_SAMPLE 0.10 I tried different programs, from "hello world" to a complex language interpreter. I always get the same file with only a header. * I also tried adding more arguments like `-hc`, `-hm`, `-hr` etc. but I got same results. I feel like the feature is broken. I checked the test suite to find some working LDV profiling programs. But as far as I can see we don't have any tests for LDV stuff. There's a `bio001.stdout` which I believe is related with "biographical profiling"(which means LDV) but again AFAICS it's not used. (I'm not having any different behaviors or exceptions while running programs using LDV RTS arguments.) Can anyone help me with this? Is anyone using this feature? Am I right that this feature is not tested? Thanks. --- Ömer Sinan Ağacan http://osa1.net

2 1

Improving the Int/Word story inside GHC
by Johan Tibell 08 Aug '14

08 Aug '14

Inside GHC we mostly use Int instead of Word, even when we want to represent non-negative values, such as sizes of things or indices into things. This is now causing some grief in https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary case test fails with a segfault because a n < m Int comparison overflows. I tried to fix the issue by changing the type of maxInlineAllocSize, which is used on one side of the above comparison, to Word. However, that unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are all Int-valued quantities. I could perhaps work around these problems by judicious use of fromIntegral in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the code uglier and 2) needs to be done in quite a few places. How much work would it be to try to switch the codegen to use Word for most of these quantities instead? -- Johan

5 15

Building GHC under Wine?
by Joachim Breitner 08 Aug '14

08 Aug '14

Hi, I feel sorry for Simon always repeatedly stuck with an unbuildable tree, and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it likely to catch the kind of problems that Simon is getting? If so, maybe it runs fast enough to be also tested by travis on every commit? (This mail is to find out if people have tried it before. If not, I’ll give it a quick shot.) Greetings, Joachim ¹ we surely can use it: http://www.haskell.org/haskellwiki/GHC_under_Wine -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 8