Re: [commit: ghc] master: Implementation of hsig (module signatures), per #9252 (aa47995)
Hi Edwardd, Am Freitag, den 24.10.2014, 23:47 + schrieb g...@git.haskell.org: --- commit aa4799534225e3fc6bbde0d5e5eeab8868cc3111 Author: Edward Z. Yang ezy...@cs.stanford.edu Date: Thu Aug 7 18:32:12 2014 +0100 Implementation of hsig (module signatures), per #9252 this breaks a few test cases: Actual stderr output differs from expected: --- ./ghci/scripts/T5979.stderr 2014-10-24 23:49:33.395524791 + +++ ./ghci/scripts/T5979.run.stderr 2014-10-25 00:24:08.934279006 + @@ -2,6 +2,6 @@ no location info: Could not find module ‘Control.Monad.Trans.State’ Perhaps you meant - Control.Monad.Trans.State (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) - Control.Monad.Trans.Class (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) - Control.Monad.Trans.Cont (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) + Control.Monad.Trans.State (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) + Control.Monad.Trans.Class (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) + Control.Monad.Trans.Cont (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) *** unexpected failure for T5979(ghci) Actual stdout output differs from expected: --- ./safeHaskell/check/pkg01/safePkg01.stdout 2014-10-24 23:49:33.705509654 + +++ ./safeHaskell/check/pkg01/safePkg01.run.stdout 2014-10-25 00:19:17.451490530 + @@ -29,17 +29,17 @@ require own pkg trusted: True M_SafePkg6 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: trustworthy require own pkg trusted: False M_SafePkg7 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: safe require own pkg trusted: False M_SafePkg8 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: trustworthy require own pkg trusted: False *** unexpected failure for safePkg01(normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/38981598/log.txt It seems you need to adjust the testsuite to remove these hashes before comparing the output. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-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://www.haskell.org/mailman/listinfo/ghc-devs
Re: Automating GHC build for Windows
2014-10-25 2:03 GMT+02:00 Austin Seipp aus...@well-typed.com: As well as that, Gabor's bots (at http://haskell.inf.elte.hu/builders) also build on Windows. Unfortunately, my builders are still suffering from the sudden breakage induced by a Cabal library update on September 24 [1]. That is, they are unable to complete the build due to some ghc-cabal failure right after bootstrapping [2]. As a result, I basically suspended the builders until I could do something with this. Yes, I have just checked it, the situation is still the same. Curiously, I do not know about others who are experiencing the same problem, however, the revisions before the referenced commit (mostly) build just fine. As of yet, I have not had the time and chance to even attempt to fix this. I have already answered Herbert the version of the build environment (Windows 7 SP1, MinGW from July 4 (32 bit) and February 16 (64 bit), with GHC 7.6.3) -- I do not even know if that was considered old or problematic. I am not also sure if the developers involved in the aforementioned change are aware of this issue and what their opinion on this is. I admit that I have not submitted a ticket on this, perhaps I shall. Probably I shall also experiment with moving to a newer version of the toolchain per the recently revamped Windows build instructions in the meantime. [1] http://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae [2] http://haskell.inf.elte.hu/builders/windows-x86-head/56/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Call Arity, oneShot or both
Hi, some months ago I tried to make foldl a good consumer in the common case. The starting point is always to write foldl k a xs = foldr (\v f a - f (v `k` a)) id xs a and then somehow make GHC produce good code with this. I came up with two solutions: A more sophisticated compiler analysis (Call Arity), or an explicit annotation in the form of foldlB k a xs = foldr (\v f - oneShot (\a - f (v `k` a))) id xs a where oneShot :: (a - b) - (a - b) is a built-in function, semantically the identity, but telling the compiler that it can assume that the (\a - ...) is called at most once. Back then, we decided to use Call Arity, on the grounds that it might improve other code as well, despite not having a lot of evindence that this may happen. Then recently David Feuer built on my work by making more functions fuse, including functions like scanl that are not built on foldl, but benefit from the same analysis. This supports the usefulness of Call Arity. But he also found cases where Call Arity is not powerful enough and GHC would produce bad code. So I wanted to properly compare Call Arity with the oneShot approach. Based on todays master (0855b249), I disabled Call Arity and changed the definitions of foldl, foldl', scanl and scanl' to use oneShot, and ran nofib. The result are mixed. With the current code, the oneShot machinery does not always work as expected: Program SizeAllocs Runtime Elapsed TotalMem Min -0.1% -1.5% -2.8% -2.8% -5.8% Max +0.4% +4.7% +5.8% +5.6% +5.4% Geometric Mean -0.0% +0.1% +0.3% +0.3% +0.1% The biggest loser is calendar, which uses scanl. I am not fully sure what went wrong here: Either the one-shot annotation on the lambda’s variable got lost somewhere in the pipeline, or despite it being there, the normal arity analysis did not use it. But there is also a winner, fft2, with -1.5% allocations. Here Call Arity was not good enough, but oneShot did the jobs. There is also the option of combining both. Then we do not get the regression, but still the improvement for fft2: Min -0.1% -1.5% -3.9% -3.8% -5.8% Max +0.2% +0.1% +6.4% +6.3%+13.1% Geometric Mean -0.0% -0.0% +0.0% +0.0% +0.1% The oneShot code is on the branch wip/oneShot. The changes are clearly not ready to be merged. In particular, there is the question of how to best keep the oneShot annotation in the unfoldings: The isOneShotLambda flag is currently not stored in the interface. I work around this by making sure that the oneShot function is never inlined in unfoldings, but maybe it would be better to serialize the isOneShotLambda flag in interfaces, which might have other good effects? If we want as much performance as possible, we should simply include both approaches. But there might be other things to consider... so not sure what the best thing to do is. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-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://www.haskell.org/mailman/listinfo/ghc-devs
Re: Call Arity, oneShot or both
Thanks for the interesting analysis Joachim. I wouldn't trust nofib's runtime numbers (but the allocation ones should be good). The tests don't run long enough and the way we don't handle typical noise issues (e.g. clock resolution, benchmark length, etc) well enough. I'd love to see some numbers using Criterion instead. It might also be worth to check for which programs the Core changed. On Sat, Oct 25, 2014 at 9:24 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, some months ago I tried to make foldl a good consumer in the common case. The starting point is always to write foldl k a xs = foldr (\v f a - f (v `k` a)) id xs a and then somehow make GHC produce good code with this. I came up with two solutions: A more sophisticated compiler analysis (Call Arity), or an explicit annotation in the form of foldlB k a xs = foldr (\v f - oneShot (\a - f (v `k` a))) id xs a where oneShot :: (a - b) - (a - b) is a built-in function, semantically the identity, but telling the compiler that it can assume that the (\a - ...) is called at most once. Back then, we decided to use Call Arity, on the grounds that it might improve other code as well, despite not having a lot of evindence that this may happen. Then recently David Feuer built on my work by making more functions fuse, including functions like scanl that are not built on foldl, but benefit from the same analysis. This supports the usefulness of Call Arity. But he also found cases where Call Arity is not powerful enough and GHC would produce bad code. So I wanted to properly compare Call Arity with the oneShot approach. Based on todays master (0855b249), I disabled Call Arity and changed the definitions of foldl, foldl', scanl and scanl' to use oneShot, and ran nofib. The result are mixed. With the current code, the oneShot machinery does not always work as expected: Program SizeAllocs Runtime Elapsed TotalMem Min -0.1% -1.5% -2.8% -2.8% -5.8% Max +0.4% +4.7% +5.8% +5.6% +5.4% Geometric Mean -0.0% +0.1% +0.3% +0.3% +0.1% The biggest loser is calendar, which uses scanl. I am not fully sure what went wrong here: Either the one-shot annotation on the lambda’s variable got lost somewhere in the pipeline, or despite it being there, the normal arity analysis did not use it. But there is also a winner, fft2, with -1.5% allocations. Here Call Arity was not good enough, but oneShot did the jobs. There is also the option of combining both. Then we do not get the regression, but still the improvement for fft2: Min -0.1% -1.5% -3.9% -3.8% -5.8% Max +0.2% +0.1% +6.4% +6.3%+13.1% Geometric Mean -0.0% -0.0% +0.0% +0.0% +0.1% The oneShot code is on the branch wip/oneShot. The changes are clearly not ready to be merged. In particular, there is the question of how to best keep the oneShot annotation in the unfoldings: The isOneShotLambda flag is currently not stored in the interface. I work around this by making sure that the oneShot function is never inlined in unfoldings, but maybe it would be better to serialize the isOneShotLambda flag in interfaces, which might have other good effects? If we want as much performance as possible, we should simply include both approaches. But there might be other things to consider... so not sure what the best thing to do is. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Improving the LLVM backend by packaging it
On 10/25/2014 12:52 AM, Austin Seipp wrote: Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment to version support, two major versions are busted, others are seriously buggy, and yet there are lots of things we could improve on. So I give you a proposal, from a few of us to you all, about improving it: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think. We'd like to do this for 7.12. I've also wrangled some people to help. Those people know who they are (because they're CC'd), and I will now badger them into submission until it is fixed for 7.12. Please let me know what you think. PS. Joachim, I would be particularly interested in upstream needs for Debian, as I know of their standard packaging policy to not duplicate things. I don't think any distro wants to duplicate things. Even if GHC does end up shipping with LLVM, it should be easy for distro packagers to ignore that and use their own. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
