Re: slow Trac
status.haskell.org Yay, that's neat. I'll keep everyone posted Thank you, Austin. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Extending fold/build fusion
To answer myself some after having fiddled with this more The failure-to-fuse is apparently only an issue if I put the fusible thing in the same module as the combinators, for reasons I can't explain. If a separate module imports and defines bar, things fuse fine. I'm still not sure what to do about the weird nil-passing definitions. I came up with one possibility, which is to create a different build: nilWrap :: b - Wrap (Simple b) b nilWrap z = Wrap (\(Simple s) e r - s e r) (\u - Simple $ \e _ - u e z) buildPlain :: (forall b f. Wrap f b - (a - b - b) - b - b) - [a] buildPlain g = g (nilWrap []) (:) [] This uses the wrapping to plug in the same nil case at every step, which eliminates the extra argument when used. But, I don't think this is usable. Some definitions are okay with this wrapper, but others aren't, and I believe that foldrW/buildW fusion can cause it to get into places where it isn't okay. For instance, if we use nilWrap in foldr, then: foldr f z (reverse xs) does the wrong thing. On Thu, Sep 4, 2014 at 5:20 PM, Dan Doel dan.d...@gmail.com wrote: I've been looking into this a bit in the past day or so, and I feel like some of the stuff in the repository doesn't make sense (to me, at least). For instance, if you start examining the generated code, you'll see quirks like, taking map as an example: map f xs = go xs [] where go xs n = case xs of [] - n y:ys - f y : go ys n In other words, the loop passes along the empty list in an argument for the base case, which is a waste. This stems from the definition of foldrW: foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' - case list of [] - z' x:xs - f x $ wrap go xs z' Specifically, the z' becomes this extra threaded argument, and never disappears. It is possible to fix this by changing the definition of foldrW to be: ... [] - z0 ... And ghc then recognizes that the z' being threaded is useless and eliminates it. But this raises the question of why it's being threaded this way in the first place. It seems like the types in Wrap are inappropriate in some way, at least for the general case. But I'm not yet certain what they should be. There are also fusion problems with the current implementation that neither I nor David have fully figured out yet. For instance: bar = map (+1) (eft 0 1000) does not fuse, even after trying many tweaks to the definitions (due to the eft 0 1000 being pulled out into a let for reasons we don't yet understand; it even happens with -fno-full-laziness). However: bar = foldl (+) 0 (map (+1) (eft 0 1000)) fuses fully. The only way to fix the former I've yet found is making buildW CONLIKE, but that may not be appropriate in general (probably isn't). I have a sneaking suspicion that the strangeness mentioned in the first part of this mail may be a contributing factor to this latter issue, too. -- Dan On Wed, Sep 3, 2014 at 3:47 PM, Joachim Breitner m...@joachim-breitner.de wrote: Dear Akio, Am Mittwoch, den 12.03.2014, 19:36 +0100 schrieb Joachim Breitner: Dear Akio, Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano: I modified the base library to use foldrW/buildW, with no changes to foldl yet. nofib showed a very big regression in cryptarithm2, so I'm looking into it. any news on this front? Did you find out what happened in cryptarithm2? Do you need help with that? I haven’t heard from you in quite some time. Are you still on this project? Recent investigations into fusion by David Feuer has increased interest in your approach (https://ghc.haskell.org/trac/ghc/ticket/9545). 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
validate --slow bugs (was Re: Status updates)
On Wed, 3 Sep 2014 15:31:03 -0500
Austin Seipp aus...@well-typed.com wrote:
Hi *,
Here are some status updates for the past week, which have been a bit light.
Woot! Great list!
- I still think we should turn on --slow mode for our buildbots soon,
but this will cause noise. I'd really like some inputs on this - maybe
someone would like to help clean up the 'slow' vaildate failures?
Bonus points for this, since you don't even have to
That's a great goal, but --slow enables compiler debug assertions,
which seem to trigger real errors (full log of failures attached).
I've filled tickets for some of those assertion failures.
If someone more experienced in the area could guide us
hints on how to fix them (CCed Simon PJ).
If they all are non-issues please tell and I'll drop them.
If they are real bugs I can try to debug them a bit
and gather more info (maybe something specific is of interest?).
Highlights:
*** unexpected failure for T3500b(threaded2)
= T3500b(dyn) 3766 of 4100 [0, 12, 0]
cd ./typecheck/should_run
'/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -o T3500b T3500b.hs -O -dynamic
T3500b.comp.stderr 21
Compile failed (status 256) errors were:
[1 of 1] Compiling Main ( T3500b.hs, T3500b.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20140905 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying RuleFired foldr/augment
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 12441
Is it bad?
cd ./ghc-api $MAKE -s --no-print-directory T8628/dev/null
T8628.run.stdout 2T8628.run.stderr
Actual stderr output differs from expected:
--- /dev/null 2014-08-25 09:46:54.593424088 +0300
+++ ./ghc-api/T8628.run.stderr 2014-09-05 22:49:20.705589132 +0300
@@ -0,0 +1,4 @@
+WARNING: file compiler/simplCore/SimplEnv.lhs, line 539
+Ghci3.$fShowX
+WARNING: file compiler/simplCore/SimplEnv.lhs, line 539
+Ghci3.$fShowX
*** unexpected failure for T8628(normal)
This looks nasty.
= tc124(hpc) 3135 of 4100 [0, 3, 0]
cd ./typecheck/should_compile
'/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -c tc124.hs -O -fhpc -hpcdir .hpc.tc124
-fno-warn-incomplete-patterns tc124.comp.stderr 21
Compile failed (status 256) errors were:
*** Core Lint errors : in result of Simplifier ***
no location info: Warning:
In the type ‘a_12 - a_aia - a_aia’
@ a_12 is out of scope
*** Offending Program ***
Foo.f :: Foo.T - (GHC.Types.Int, GHC.Types.Char)
[LclIdX,
Arity=1,
Str=DmdType,
Unf=Unf{Src=vanilla, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 90 30}]
This also looks scary.
Thanks!
--
Sergei
make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt
make[1]: ÐÑ
од в каÑалог
`/home/slyfox/dev/git/ghc-validate/testsuite/tests'
python2 ../driver/runtests.py -e ghc_compiler_always_flags='-fforce-recomp
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts ' -e
ghc_debugged=True -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e
ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e
ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e
ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e
ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e
clean_only=False --rootdir=. --config=../config/ghc -e
'config.confdir=../config' -e
'config.compiler=/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/ghc' -e
'config.ghc_pkg=/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/ghc-pkg' -e
'config.hp2ps=/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/hp2ps' -e
'config.hpc=/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/hpc' -e 'config.gs=gs' -e 'config.platform=x86_64-unknown-linux'
-e 'config.os=linux' -e 'config.arch=x86_64' -e 'config.wordsize=64' -e
'default_testopts.cleanup=1' -e 'config.timeout=int() or config.timeout' -e
'config.timeout_prog=../timeout/install-inplace/bin/timeout' -e
'config.exeext=' -e
'config.top=/home/slyfox/dev/git/ghc-validate/testsuite' --output-summary
../../testsuite_summary.txt --rootdir=../../libraries/array/tests
--rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests
--rootdir=../../libraries/bytestring/tests
--rootdir=../../libraries/containers/tests
Re: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6
I have happened to find seemingly related bug in PIC handing on other PIC-sensitive RISCs: https://phabricator.haskell.org/D177 (also in ghc's master) I think it might help you to get ghci on your mipsel. The following error occurred on 31f43e806beeac434b1330ba5a04746ae79275fc: /usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaske_2vN4xw6O9xk8OwkNKI7sbg.a rm -f libraries/haskeline/dist-install/build/libHShaske_2vN4xw6O9xk8OwkNKI7sbg.a.contents Panic! libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.hi exists, but libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o does not. make[1]: *** [libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o] Error 1 make: *** [all] Error 2 pgpqgj8z0BNwU.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: slow Trac
Hi, Am Freitag, den 05.09.2014, 03:21 -0500 schrieb Austin Seipp: Update: Trac should be much more responsive now (and Hackage too), but Hackage still needs more investigation. Still ongoing for the moment... I’m still observing bad response times, and errors like database locked. If they are gone when I do the HIW Trac+Phab demo, that’d be great. 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: slow Trac
Hmmm, Trac is running a high CPU now. I'm looking at it. We had a problem a few weeks ago with aggressive webspiders crawling/indexing the changesets for GHC, which put Trac at a relatively high load as it computed lots of diffs. We redirected the changeset view temporarily - I'm looking at why it's all cranky now. FWIW, Phabricator is located in an entirely separate part of the world with its own dedicated resources (including buildbot for patches), and should be unaffected. In fact, I think I know how to speed up the page load times even further for Phab... On Fri, Sep 5, 2014 at 4:34 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Freitag, den 05.09.2014, 03:21 -0500 schrieb Austin Seipp: Update: Trac should be much more responsive now (and Hackage too), but Hackage still needs more investigation. Still ongoing for the moment... I’m still observing bad response times, and errors like database locked. If they are gone when I do the HIW Trac+Phab demo, that’d be great. 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 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
