Re: GHC build time graphs
On 02/12/16 09:02 PM, Reid Barton wrote: btw, just recent experience on ARM64 (X-gene board): bootstrapping 7.10.1 with 7.6.x took: ~120 minutes bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes both run as: ./configure; time make -j8 It would be interesting to have the time for bootstrapping 7.10.1 with 7.10.1 too, for comparison. Good idea, build is running, but is sluggish just from the first sight. Running already for 1h20m and still building stage1. This is more in line with 8.0.1 I'm afraid. Anyway, I'll update with proper time once it is at the end. Looks like I'll also need to do 7.8.x build to see where we are on this... Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick performance measurements
Hi, Am Freitag, den 12.02.2016, 14:04 -0500 schrieb Richard Eisenberg: > Ideally, there would be a way to run a portion of the testsuite and > have the testsuite tool aggregate performance characteristics and > report. if you run the test suite with $ VERBOSE=4 you get the detailed stats for every perf test, not only for the failing ones. This is what the gipeda runner does. You’d still have to manually compare them, though; no aggregation happening. Also, the compiler perf test cases usually check one specific extreme code path, so they are not a good measure of real world performance. nofib is better there, and has comparing integrated, but only checks those parts of the compiler that deal with idiomatic Haskell code from 10 or 20 years back. Maybe I should write a text that explains how to run gipeda locally on a bunch of commits on a local branch... but it’s only making the results more shiny, not more significant, than running nofib or the test suite manually. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick performance measurements
Richard Eisenberg writes: > Hi devs, > > I have a few ideas for tweaks to improve compiler performance. (For > example, reversing the order of comparisons in a short-circuiting > comparison operation.) I don't have a particular test case with a > profile that tells me where the smoking gun is. But I'd like to try > these easy tweaks just to see if performance improves. > > My question: Is there an easy way to run some command that will give > me helpful feedback on my performance tweak? > > Of course, I could push to a branch and have perf.haskell.org tell me. > But that takes a long time. I could compile a few files and examine > the output manually. But that's a bit painful. Ideally, there would be > a way to run a portion of the testsuite and have the testsuite tool > aggregate performance characteristics and report. Or perhaps there's a > way to get cabal to aggregate performance characteristics, and I could > just try compiling a few libraries. Any ideas out there? > Indeed I wish we had better infrastructure for this. There is nofib, which IIRC tracks compile-time performance although the coverage isn't terribly great. Otherwise, beyond tweaking the testsuite driver as thomie suggests the options are sadly fairly limited. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick performance measurements
You could tweak the function `checkStats` in `testsuite/driver/testlib.py` a bit, to not only report failures. Maybe also disable the following check, if you're doing this from a debug build: # Compiler performance numbers change when debugging is on, making the results # useless and confusing. Therefore, skip if debugging is on. if compiler_debugged(): skip(name, opts) On Fri, Feb 12, 2016 at 9:30 PM, Richard Eisenberg wrote: > > On Feb 12, 2016, at 3:28 PM, Simon Peyton Jones > wrote: > > > cd testsuite/tests/perf; make > > But that tells me only about failures. What if I have a tweak that makes > an average 1% improvement over lots of files? That would be a nice > improvement, but we don't have an easy way to collect this info, I think, > other than perf.haskell.org. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick performance measurements
On Feb 12, 2016, at 3:28 PM, Simon Peyton Jones wrote: > cd testsuite/tests/perf; make But that tells me only about failures. What if I have a tweak that makes an average 1% improvement over lots of files? That would be a nice improvement, but we don't have an easy way to collect this info, I think, other than perf.haskell.org. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: quick performance measurements
cd testsuite/tests/perf; make | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard | Eisenberg | Sent: 12 February 2016 19:04 | To: ghc-devs@haskell.org developers | Subject: quick performance measurements | | Hi devs, | | I have a few ideas for tweaks to improve compiler performance. (For example, | reversing the order of comparisons in a short-circuiting comparison | operation.) I don't have a particular test case with a profile that tells me | where the smoking gun is. But I'd like to try these easy tweaks just to see | if performance improves. | | My question: | Is there an easy way to run some command that will give me helpful feedback | on my performance tweak? | | Of course, I could push to a branch and have | https://na01.safelinks.protection.outlook.com/?url=perf.haskell.org&data=01%7 | c01%7csimonpj%40064d.mgd.microsoft.com%7cb2e1edc8a6f248a9066508d333df5623%7c7 | 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=wU6DNmX%2bLF8sagU0B9yJAh4MKJ3yJc1CA | omIiSI%2fqvM%3d tell me. But that takes a long time. I could compile a few | files and examine the output manually. But that's a bit painful. Ideally, | there would be a way to run a portion of the testsuite and have the testsuite | tool aggregate performance characteristics and report. Or perhaps there's a | way to get cabal to aggregate performance characteristics, and I could just | try compiling a few libraries. Any ideas out there? | | Thanks! | Richard | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cb2e1edc8a6f248a9066508 | d333df5623%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JnjGw%2fk%2brdNGy9VNY | 0m1KA7Ojr2ubJO6PneeGVL4LmY%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC build time graphs
On Tue, Feb 9, 2016 at 11:20 AM, Karel Gardas wrote: > On 01/28/16 11:34 PM, Ben Gamari wrote: > >> Joachim Breitner writes: >> >> Hi Oleg, >>> >>> Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: >>> Is the same compiler used to build HEAD and 7.10,1? >>> >>> Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built >>> with 7.10.3. >>> >>> Anthony’s link, i.e. >>> >>> https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85 >>> has links to the build logs of either build; there I could find that >>> information. >>> >>> That might be (part) of the problem. But if it is, it is even worse, as >>> it would mean not only building the compiler got slower, but the >>> compiler itself... >>> >>> I can verify that the build itself is indeed slower. Validating the >> current state of ghc-7.10 takes 19 minutes, whereas ghc-8.0 takes 25.5 >> minutes. This isn't entirely unexpected but the change is quite a bit >> larger than I had thought. It would be nice to know which commits are >> responsible. >> > > btw, just recent experience on ARM64 (X-gene board): > > bootstrapping 7.10.1 with 7.6.x took: ~120 minutes > bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes > > both run as: ./configure; time make -j8 > It would be interesting to have the time for bootstrapping 7.10.1 with 7.10.1 too, for comparison. Regards, Reid Barton ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
quick performance measurements
Hi devs, I have a few ideas for tweaks to improve compiler performance. (For example, reversing the order of comparisons in a short-circuiting comparison operation.) I don't have a particular test case with a profile that tells me where the smoking gun is. But I'd like to try these easy tweaks just to see if performance improves. My question: Is there an easy way to run some command that will give me helpful feedback on my performance tweak? Of course, I could push to a branch and have perf.haskell.org tell me. But that takes a long time. I could compile a few files and examine the output manually. But that's a bit painful. Ideally, there would be a way to run a portion of the testsuite and have the testsuite tool aggregate performance characteristics and report. Or perhaps there's a way to get cabal to aggregate performance characteristics, and I could just try compiling a few libraries. Any ideas out there? Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC performance dashboard question
Hi Janek, Am Freitag, den 12.02.2016, 08:36 +0100 schrieb Jan Stolarek: > Joachim, what do I need to do to have my wip/ branch picked up by the > performance dashboard? I'm > thinking about branch wip/js-hoopl-cleanup, which was pushed > yesterday but still hasn't been > measured for performance. wip/ branches have lower precedence than the master branch, so in busy times, it just takes a while. But by now, the branch has been measured. But no noticable change: https://perf.haskell.org/ghc/#compare/c6485d5e6daec20c8ff66d6e721d3e0a5f3156ac/a1931b9f28b1b44cc67b1666719db5ff46ee19ef Greetings, Joachim -- -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Validation failures
Ben Gamari writes: > Simon Peyton Jones writes: > >> I’m getting this on a clean HEAD. Is anyone else? >> Simon >> >> Unexpected stat failures: >>perf/compiler T5030 [stat not good enough] (normal) >>perf/compiler T9872b [stat not good enough] (normal) >>perf/compiler T9872c [stat not good enough] (normal) > > I suspect this may have been due to niteria's piResult patch. I noticed > similar failures when attempting to merge his patch and meant to return > to the matter but forgot leave a comment on the Diff. > In fact niteria reverted the patch in question so hopefully it these should now be gone. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Validation failures
Simon Peyton Jones writes: > I’m getting this on a clean HEAD. Is anyone else? > Simon > > Unexpected stat failures: >perf/compiler T5030 [stat not good enough] (normal) >perf/compiler T9872b [stat not good enough] (normal) >perf/compiler T9872c [stat not good enough] (normal) I suspect this may have been due to niteria's piResult patch. I noticed similar failures when attempting to merge his patch and meant to return to the matter but forgot leave a comment on the Diff. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Validation failures
I’m getting this on a clean HEAD. Is anyone else? Simon Unexpected stat failures: perf/compiler T5030 [stat not good enough] (normal) perf/compiler T9872b [stat not good enough] (normal) perf/compiler T9872c [stat not good enough] (normal) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[Template Haskell] Desugaring TH brackets vs. Desugaring normal HsExprS.
Hi, I'm currently trying to understand GHC's implementation of Template Haskell and I've had the following two questions when reading upon deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete newbie to GHC and do not know pretty much anything about its internals; so please excuse silly questions). 1) As far as I understand DsMeta, its purpose is to desugar the contents of TH quotation brackets, e.g. [| \x -> x |]. Given the HsExpr contents, say `expr`, of a quotation bracket, it creates a CoreExpr /representation/ of `expr` such that /evaluating/ this CoreExpr representation yields a TH expression equivalent to `expr`. (This is similar to how quotations are implemented in the original TH paper). On the other hand, when instead writing the above TH quote, (i.e., [| \x -> x |]), explicitly as newName "x" >>= (\x -> lamE (varP x) (varE x)) (*) there is no need to build a CoreExpr /representation/ because we already got the TH value we're interested in; Hence, in this case DsExpr desugars the above (*) directly to a CoreExpr that represents it. Is my understanding of the above correct? I tried to confirm it using the following to splices: test1 :: Q Exp test1 = [| \x -> x |] test2 :: Q Exp test2 = do x <- newName "x" lamE [(varP x)] (varE x) However, dumping the desugared output of these splices using `-ddump-ds` gives the exact same CoreExprS: test1 :: Q Exp [LclIdX, Str=DmdType] test1 = Language.Haskell.TH.Syntax.bindQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a399 :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a399) (GHC.Types.[] @ PatQ)) (varE x_a399)) test2 :: Q Exp [LclIdX, Str=DmdType] test2 = >>= @ Q Language.Haskell.TH.Syntax.$fMonadQ @ Name @ Exp (newName (GHC.CString.unpackCString# "x"#)) (\ (x_a39a :: Name) -> lamE (GHC.Types.: @ PatQ (varP x_a39a) (GHC.Types.[] @ PatQ)) (varE x_a39a)) Could anyone explain to me why both CoreExpr dumps are the same? Shouldn't the first be a /representation/ that, only when run, yields the second CoreExpr? If anyone could help me understanding this, it'd be great! Thanks, Dominik. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
