Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems
Markus Barenhoff wrote:
I've updated my source tree today.
But now I've problem while compiling the ghc
Here is the the build output:
[...]
/usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc
-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211
-hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen
-ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn
-iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg
-ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise
-idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build
-I../libffi/build/include -Istage2plus -I../libraries/base/cbits
-I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include
-optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir
dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package
array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package
containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1
-package haskell98-1.0.1.0 -package hpc-0.
5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package
template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
-fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples
-XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls
-XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types
-XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf
p_o -idist-stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs
-o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20081211 for x86_64-unknown-freebsd):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081211:MachRegs !}
ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
eta_s2Ni{v} [lid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This is a known problem with the build right now. I'll try to install a
fix this week, but in the meantime you can avoid building profiled
libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the
line that says 'BuildFlavour = quick'.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Here are some figures: ghc-6.8.2 -O2 apply MVarstrict thr-N2 thr-N1 silicium 7.307.95 7.23 15.25 14.71 neghip4.254.43 4.186.67 6.48 hydrogen 11.75 10.8210.99 13.45 12.96 lobster 55.851.5 57.676.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Malcolm Wallace wrote: It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Entirely possible - unless there's any actual parallelism, running on multiple cores will probably slow things down due to thread migration. Here are some figures: ghc-6.8.2 -O2 apply MVarstrict thr-N2 thr-N1 silicium 7.307.95 7.23 15.25 14.71 neghip4.254.43 4.186.67 6.48 hydrogen 11.75 10.8210.99 13.45 12.96 lobster 55.851.5 57.676.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. So you're not getting any parallelism at all, for some reason your program is sequentialised. There could be any number of reasons for this. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) That would seem to indicate that your program is doing a lot of communication - I'd look at trying to reduce that, by increasing task size or whatever. However, the amount of communication is obviously not the only issue, there also seems to be some kind of dependency that sequentialises the program. Are you sure that you're not accidentally communicating thunks, and hence doing all the computation in one of the threads? That's a common pitfall that has caught me more than once. Do you know roughly the amount of parallelism you expect - i.e. the amount of work done by each thread? When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. That would be good. At some point we hope to provide some kind of visualisation to let you see where the parallel performance bottlenecks in your program are; there are various ongoing efforts but nothing useable as yet. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Malcolm Wallace wrote: Simon Marlow marlo...@gmail.com wrote: Malcolm Wallace wrote: For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? Exactly so - it hits the worst case behaviour. This was a naive attempt to parallelise an algorithm by shifting some work onto a spare processor. Unfortunately, there is a lot of communication to the main thread, because the work that was shifted elsewhere computes a large data structure in chunks, and passes those chunks back. The main thread then runs OpenGL calls using this data -- and I believe OpenGL calls must run in a bound thread. This all suggests that one consequence of ghc's RTS implementation choices is that it will never be cheap to compute visualization data in parallel with rendering it in OpenGL. That would be a shame. This was exactly the parallelism I was hoping for. I'm not sure how we could do any better here. To get parallelism you need to run the OpenGL thread and the worker thread on separate OS threads, which we do. So what aspect of the RTS design is preventing you from getting the parallelism you want? It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. If you still do asynchronous communication and yet don't get good parallelism, then we should look into what's causing that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
length of module name affecting performance??
Hi While trying to see if I could make some code run faster I stumbled upon something that looks weird to me: 2x-3x performance loss when a module is renamed to a longer name! Here's what I see with the attached examples: #diff long-modname-ver.hs short-modname-ver.hs 2c2 import VeryLongModuleName --- import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 module VeryLongModuleName --- module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver /dev/null real 22.23 user 21.97 sys 0.10 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Thanks Daniel files.tgz Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
Hi I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Wow. Awesome bug! Got lots of discussion at Galois :) I can confirm a difference in running time, we also tested with 6.8.x and 6.10, with similar results. Is -O2 implying -fvia-C? If so, could it be the evil mangler? Is there a non-alpha rename difference in the Core? Very cool bug :-) Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
That's a truly awesome feature! I'll shorten all my module names to single letters tomorrow. -- Lennart On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote: dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
Ditto. Can I claim the [A-Z].* hierarchies as belonging to me? :-) --sigbjorn putting them up on eBay afterwards...maybe On 12/15/2008 18:00, Lennart Augustsson wrote: That's a truly awesome feature! I'll shorten all my module names to single letters tomorrow. -- Lennart On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote: dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: length of module name affecting performance??
On Dec 15, 2008, at 10:43 PM, Don Stewart wrote: dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don done! http://hackage.haskell.org/trac/ghc/ticket/2884 thanks, daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
