- ghc-devs - Haskell.org

RE: [commit: ghc] master: Update various performance benchmarks (194107e)
by Simon Peyton Jones 14 Jul '14

14 Jul '14

| I started monitoring perfomance on a per-commit base. These seem to | be | off for a while now. Adjusting them, and from now I hope I can keep | closer tabs on them. Thank you. That's most helpful. One of the reasons that perf tests get worse is that each time the limit is reached, the author thinks "oh my bit probably only made it a tiny bit worse", so we miss big jumps. It's the big jumps we thereby miss, and nailing them to a particular commit would be great. I'ts important to monitor the actual bump, rather than the first time the limit is broken. (They aren't the same, of course.) Simon

2 1

Put GHC on travis for real
by Joachim Breitner 14 Jul '14

14 Jul '14

Hi, with all packages as submodules, ghc-complete (which is basically a git repository tracking the „fingerprint“ of the main repository) is obsolete. So we could move the travis-checking of the main line to run on the ghc repository directly. This would require * adding a .travis.yaml based on the contents of https://github.com/nomeata/ghc-complete/blob/master/.travis.yml and https://github.com/nomeata/ghc-complete/blob/master/validate.sh to the repository. * enabling Travis for this repository. I can do the former, but the latter needs to be done by a member of the “ghc” on GitHub. I can do the latter (and keep managing the travis instance) if someone adds me to the organization... Greetings, Joachim -- 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

4 6

Huge space leak of GHC API 7.8.x?
by Kazu Yamamoto 14 Jul '14

14 Jul '14

Hi, Some guys reported to me that ghc-mod uses about 1G bytes on Mac and I can reproduce this. I tried to understand why ghc-mod uses such huge memory. I found that GHC API 7.8.x uses much more memory than GHC API 7.6.x. Attached two files demonstrate this: - A.hs -- Simple program using GHC API (copied from Wiki) - B.hs -- A target file, just hello world You can compile A.hs as follows: % ghc A.hs -package ghc -package ghc-paths The following is the result: Mac (64bit) Linux (64bit) GHC 7.6.3: 20MB 4MB GHC 7.8.3: 106MB 13MB So, I think GHC API 7.8.x has huge space leak. (And I'm wondering why Mac uses much more memory than Linux). I would like to hear opinions from you guys. --Kazu <A.hs> import Control.Concurrent import CoreMonad (liftIO) import DynFlags import GHC import GHC.Paths (libdir) main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags let dflags' = dflags {hscTarget = HscInterpreted ,ghcLink = LinkInMemory ,ghcMode = CompManager } setSessionDynFlags dflags' target <- guessTarget "B.hs" Nothing setTargets [target] load LoadAllTargets liftIO $ threadDelay 10000000 </A.hs> <B.hs> module B where main = print "Hello, World!" </B.hs>

3 3

Trac spam
by Simon Peyton Jones 14 Jul '14

14 Jul '14

Dear GHC devs Is it possible to stop spam on GHC's Trac? Simon -----Original Message----- From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC Sent: 14 July 2014 04:24 Cc: ghc-tickets(a)haskell.org Subject: [GHC] #9310: This Cleanse Ultima is very beneficial to regulate a good blood circulation #9310: This Cleanse Ultima is very beneficial to regulate a good blood circulation ------------------------------------+----------------------------------- ------------------------------------+-- Reporter: joerjpool | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Cleanse Ultima | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+----------------------------------- ------------------------------------+-- He something that would punish if you feel something in the question is how are you actually going to do I liked it physically working mostly stress myself out our food Afghani book more than half my life when hapless seafood gumbo I have Lucy golf when Wane have you know some sushi or thought not downtown today know what more you deprive yourself the more you want be changed when you get sold week we're not moving why outtakes house days fish they still hadn't fully fused week you some two dozen times but hey it happens that I wanted to take a little bit it is not a little bit better which will find few lost five straight days %uh week yeah I want to our ERP user roughly everything you worked so hard for all anyway so if not before keep good food you know people who you are happy light snack crackers and stuff like that my skate since I people I illegal you know I was clapping her [http://cleanseultima-uk.com/ Cleanse Ultima] hands they know they're not going to be. and what any death of Natalie wasting money first off secondly it’s not Billy is not going to help you get through your weight loss process some things that hike to do was keep so I may even take don't use to the fact that I sweet potato chips actually sweet potato fries around Kasha pizza its peak but I'll be healthy so what's that me he likes me happy nasty old who was involved you don't mind any something around the time I sleep he on a healthy track remind mean my healthy lifestyle ha-ha sweet shocking video must if you see how check on the food eat some other schools that joy hey stop talking hospital all major install look back up debt but soon up today work 350 pounds on top it's not worth it if you have some see accident I just have work 18th dub step make use of your own you created movie didn't happen ask. http://cleanseultima-uk.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets

3 2

HaRe and incremental type checking / type inference
by AlanKim Zimmerman 13 Jul '14

13 Jul '14

I have hit a problem in HaRe when lifting a declaration from e.g. a where clause of a function to the top level, where there is a type signature of any complexity. e.g lifting 'baz' from function 'foo' below -------------------------- foo a = baz where baz :: Int baz = xx 1 a xx :: (Num t) => t -> t -> t xx p1 p2 = p1 + p2 -------------------------------------- becomes --------------------------------------------- foo a = (baz xx a) where xx :: (Num t) => t -> t -> t xx p1 p2 = p1 + p2 -- baz:: (forall t. Num t => t -> t -> t) -> Int ->Int baz :: Num a => (a -> t1 -> t) -> t1 -> t baz xx a= xx 1 a ----------------------------------------------- For a very small subset this can be calculated easily, but for full generality it would be great to access the full power of the GHC type system. So before diving in too deeply, I thought I would test the waters as to the feasibility of doing something like this. I was hoping that perhaps the effort at an external constraint solver might be making the interfacing slightly simpler. Regards Alan

2 4

gcc vs. clang builds of 7.8.3 on OS X
by Mark Lentczner 13 Jul '14

13 Jul '14

In building the OS X bindist for 7.8.3, I had to choose which of several ways to build it. In particular, I could build it with a newere Xcode, which uses clang, or an older Xcode which uses gcc. I decided to nofib benchmark the variations and see before I released. Here is what I found... I compared two candidate builds: - x86_64 architecture - targeted at OS X 10.7 and later - one built with Xcode 5.1 on 10.9, which uses clang - one built with Xcode 4.5 on 10.8, which uses gcc I installed both bindists, side-by-side on the same machine: a 10.9 machine, with Xcode 5.1, which uses clang. The machine is a MacMini, 2.5GHz Intel Core i5 (dual core, reports as 4 cpus). Summary: - clang build was always faster - non-threaded was -3.2% run-time - threaded was -7.3% run-time - clang's improvement in GC run-time was better than -10% - clang builds were significantly bigger You can find the details here: - analysis-Silver-10.9-gcc-vs-clang.html <http://www.ozonehouse.com/mark/platform/analysis-Silver-10.9-gcc-vs-clang.h…> - analysis-Silver-10.9-gcc-vs-clang-threaded.html <http://www.ozonehouse.com/mark/platform/analysis-Silver-10.9-gcc-vs-clang-t…> The only concern is that the binary sizes were significantly bigger: +230% - I haven't investigated more, but I'm wondering if nofib doesn't strip the binaries before measuring, and perhaps clang's debugging info is much greater? Next up... we are evaluating a bindist built with the HPC Mac OS X gcc compiler (based on gcc 4.9)... and preliminary results are looking even better! Stay tuned... - Mark

4 9

Proposal: require Haddock comment for every new top-level function and type in GHC source code
by Johan Tibell 13 Jul '14

13 Jul '14

Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with "notes", which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: - Programmers comment code they think is "complex enough to warrant a comment". The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. - Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. *Proposal: *I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong "broken window" effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. *First example* In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was "what does RUR stand for?" Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean "read" in the enclosing function and "updating" is related to "reading" so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting platform) src That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. *Second example* In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: -- | Returns which registers are read and written by this -- instruction, as a (read, written) pair. This info is used -- by the register allocator. x86_regUsageOfInstr :: Platform -> Instr -> RegUsage The reason mentioning that the return value is essentially a (read, written) pair is helpful is because the body of the function a big case statement full of lines like this one: GCMP _ src1 src2 -> mkRUR [src1,src2] ... FDIV _ src dst -> usageRM src dst It's not immediately clear that all the various helper functions used here just end up computing a pair of the above form. A top-level comment lets you understand what's going on without understanding exactly what all these helper functions are doing. Thoughts? -- Johan

15 23

Re: [GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by Levent Erkok 13 Jul '14

13 Jul '14

So, it appears that the one ending with 21 is the likely correct result; as opposed to 22. Is this an issue with some underlying library (glibc etc.); or an issue with GHC itself? On Sat, Jul 12, 2014 at 8:03 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9304: Floating point woes; Different behavior on Mac vs Linux > -------------------------------------+------------------------------------ > Reporter: lerkok | Owner: > Type: bug | Status: new > Priority: high | Milestone: > Component: Compiler | Version: 7.8.3 > Resolution: | Keywords: floating point > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: 9276 > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by carter): > > I ran it on a 64 bit linux server i have using ghci > {{{ > Prelude> :set -XScopedTypeVariables > Prelude> let x :: Double = -4.4 > Prelude> let y :: Double = 2.4999999999999956 > Prelude> decodeFloat (x*y) > (-6192449487634421,-49) > > }}} > > so if anything, it looks like its 32bit vs 64bit > > could you try running the above snippet in GHCi on your 32bit machine? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304#comment:4> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Note: Phabricator can now build code reviews!
by Austin Seipp 12 Jul '14

12 Jul '14

Hi *, Quick notice: I spent some time hacking to get Phabricator to build code reviews you publish against the GHC repository. It luckily was not that hard to do so - hooray! Go here for an example: https://phabricator.haskell.org/D64 Look at the top set of information, and find 'Build Status'. This points to the current build being produced for this revision. Icon colors are - red is failed, blue is in progress, green means good. The build is driven by an application called 'Harbormaster'. Harbormaster makes an HTTP request when a new diff is posted, which triggers a build on a backend system that applies the diff and runs ./validate. Now, look at this specific link: https://phabricator.haskell.org/D64#16 I updated the diff, and the build failed and notified Harbormaster. This adds a notification to the page (just below the comment I linked), emails interested parties, and marks the build status at the top. After a build happens, a bot named `phaskell` will drop by and give some results. Validate logs are gzip'd, and uploaded to Phabricator as .txt.gz files. You can download them and look at the full results. If the build fails, the tests that failed are output in the comment on the revision automatically. Builds happen per diff. This means they happen every time you run 'arc diff'. This is all extremely new. Please be nice to it. :) However - if you have some cool changes, please post them! I might just post some to let it do ./validate - it's nice if the machines can just do the work and you can be lazy. :) In the future, Phabricator's Drydock and Harbormaster applications will expand to hopefully do this on their own, with no custom infrastructure from us. We can also utilize resources more effectively. Here's where you can look for the current build queue: https://phabricator.haskell.org/harbormaster/query/all/ The build queue is currently serial - that means the system only runs one build at a time on a 4 core dedicated machine. This simplifies the management but it does mean it could get slightly backed up. It's only a 30 minute wait to validate something though, and that can probably be improved further. Next up: Linking Phabricator to Trac. P.S. The way it works technically is Phabricator -> HTTP GET -> Build machine. This machine runs an HTTP Server - a Python Flask server that simply runs a build script, which reports back to phabricator.haskell.org with JSON requests. Phabricator requests are HTTPS secured. GET requests are securely tunneled over an encrypted pipe (spiped). This build script update Harbormaster's status, post comments, and uploads the build log. Source code: https://github.com/haskell-infra/phab-ghc-builder -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Status of Haskell Platform 2014.2.0.0
by Mark Lentczner 11 Jul '14

11 Jul '14

The status is: *Good-to-Go!* The new-build branch of Haskell Platform is in pretty great shape: - One consistent build system using Shake - Builds source tarball - Builds linux distribution tarball - Builds Mac installer - Builds in one command line from a GHC bindist to end-user installer! - We have a running travis-ci instance <https://travis-ci.org/haskell/haskell-platform>* (currently red as we await a 7.8.3 bindist)* As soon as GHC 7.8.3 is out, I'll be running an alpha (or is this rc1?) or Haskell Platform (well, after I build the bindists for GHC for Mac... so it'll be a few hours on my puny MacBook Air...) *Shout out to: Yitzchak Gale, Bob Ipoloito, and Randy Polen for lots of help with the new build; Carter Schonwald for Mac and GHC build issues; Robert Lefkowitz for wiki and issue converstion (now on github!); Neil Mitchell for consultations on Shake.* The platform is now in a place that we'll be able to turn it much more quickly. This means we can track GHC release more closely, handle important library fixes when needed. And more importantly, spend time improving the platform itself, rather than sapping our energies build it! What you need to do now: - Check the version list in Release2014.hs <https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Relea…> - If you see a problem with the version of your library, let us know - If you are a packager for one of the linux distros - please try out the build and see how it works, and how it meshes with your packaging process for the distro. Come talk to me if you need help or brainstorming w.r.t. to the new-build. - If you have a Mac, you can try building the platform. *Build note: The repo is in sync with head of GHC 7.8 and we've been working with bindists we build ourselves off of head. If you want to try out the HP build with a 7.8.2 bindist, you'll need to change the version of base back to 4.7.0.0.* What you can do to help There are few aspects in progress, but none of these are show stoppers: - Windows installer using the new build being written by Randy Polen. (Existing windows build from the source tarball is still possible) - contact him if you'd like to help. - Platform website is being revamped by Erin Depew in concert with the general Haskell redesign by Chris Done - Platform website is template generated... but the pages haven't been templated much. if you're interested, e-mail and I can supply more details and hook up interested parties and Erin. - The travis-ci instance is enabled for Mac builds, but isn't configured to do them right. - There is a TO DO small task list in BUILD-NEW <https://github.com/haskell/haskell-platform/blob/new-build/notes/BUILD-NEW#…> in the repo - I'd like to see the As and Bs done. If you want to tackle one just do it and send me a merge request. - Many people have asked for a "server edition" of the platform w/o packages that don't make sense on a server (such as the OpenGL stuff). The new-build could easily be extended to do this now. - I'd love to see a version of Simon Hengel's Haskell Platform Versions Comparison Chart <http://sol.github.io/haskell-platform-versions-comparison-chart/> as part of the platform website. Now that it is templatized and the raw data is in Haskell, it should be possible. (I have prior year's data in the right format, just not checked in, ask me...) - It would be wonderful if we could get tests incorporated: Both running the tests that are part of the included libraries, and perhaps some "big integration tests" (is compiling Pandoc enough?). It would be great if these tests can be run "in-place" after the platform is built (for travis-ci), and if they could be run on the target machine (post-installation). — Mark "is it July already?" Lentczner

5 4