February 2013 - ghc-tickets

Re: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator)
by GHC 07 Feb '13

07 Feb '13

#2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by JohnWiegley): Cc -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2959#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator)
by GHC 07 Feb '13

07 Feb '13

#2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * cc: andy.adamsmoran@… (added) Comment: What's the status of LambdaVM? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2959#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 07 Feb '13

07 Feb '13

#5793: make nofib awesome --------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: _|_ Component: NoFib benchmark suite | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5794 Related: | --------------------------------------+------------------------------------- Description changed by dterei: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > 2. Fixup the runtimes for benchmarks to be significant. (A lot of them > run in < 1 or < 0.1 seconds). I think trying to get all of them to run in > around 10s is a good target. > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. 2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful. E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2207: Load the interface details for GHC.* even without -O
by GHC 07 Feb '13

07 Feb '13

#2207: Load the interface details for GHC.* even without -O ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: lowest => normal * milestone: 7.6.2 => _|_ -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2207#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7017: Rethink need for tarballs under "friendly" environment
by GHC 07 Feb '13

07 Feb '13

#7017: Rethink need for tarballs under "friendly" environment ---------------------------------+------------------------------------------ Reporter: FUZxxl | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7017#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5909: Segfault with multi-threaded retainer profiling
by GHC 07 Feb '13

07 Feb '13

#5909: Segfault with multi-threaded retainer profiling -------------------------------+-------------------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by simonmar): Interesting, thanks for the patch, I'll take a look. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5909#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5909: Segfault with multi-threaded retainer profiling
by GHC 07 Feb '13

07 Feb '13

#5909: Segfault with multi-threaded retainer profiling -------------------------------+-------------------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by akio): * status: new => patch Comment: I think I have found a bug. Segfaults often happen in the isMember function in rts/RetainerSet.h. It gets a segfault when tries to dereference rs, whose value is 0x4 or 0x6: {{{ (gdb) run aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K Starting program: /home/akio/src/test/segfault aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff6acd700 (LWP 14398)] [New Thread 0x7ffff62cc700 (LWP 14399)] [New Thread 0x7fffe7fff700 (LWP 14400)] [New Thread 0x7fffeffff700 (LWP 14401)] [New Thread 0x7ffff56ff700 (LWP 14402)] [New Thread 0x7ffff4efe700 (LWP 14403)] Program received signal SIGSEGV, Segmentation fault. isMember (rs=<optimized out>, r=0xd46640) at rts/RetainerSet.h:140 140 if (rs->num < BINARY_SEARCH_THRESHOLD) { (gdb) bt #0 isMember (rs=<optimized out>, r=0xd46640) at rts/RetainerSet.h:140 #1 retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1625 #2 0x0000000000946c4e in retain_PAP_payload (pap=0x7ffff5768190, c_child_r=0xd46640, fun=<optimized out>, payload=0x7ffff57681b8, n_args=1) at rts/RetainerProfile.c:1413 #3 0x0000000000946674 in retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1686 #4 0x0000000000951e4f in markStablePtrTable (evac=0x946a60 <retainRoot>, user=0x0) at rts/Stable.c:364 #5 0x00000000009471b5 in computeRetainerSet () at rts/RetainerProfile.c:1775 #6 retainerProfile () at rts/RetainerProfile.c:1979 #7 0x0000000000943be0 in heapCensus (t=<optimized out>) at rts/ProfHeap.c:1086 #8 0x000000000095bd0a in GarbageCollect (collect_gen=<optimized out>, do_heap_census=rtsTrue, gc_type=<optimized out>, cap=0xd57240) at rts/sm/GC.c:735 #9 0x000000000094e7a8 in scheduleDoGC (pcap=<optimized out>, task=0xdc7740, force_major=rtsFalse) at rts/Schedule.c:1643 #10 0x000000000094f4b2 in schedule (initialCapability=<optimized out>, task=0xdc7740) at rts/Schedule.c:553 #11 0x0000000000950a15 in scheduleWaitThread (tso=<optimized out>, ret=<optimized out>, pcap=0x7fffffffe040) at rts/Schedule.c:2345 #12 0x00000000009498ee in real_main () at rts/RtsMain.c:63 #13 0x00000000009499ea in hs_main (argc=7, argv=0x7fffffffe1a8, main_closure=0xcb99b0, rts_config=...) at rts/RtsMain.c:114 #14 0x0000000000407f47 in main () (gdb) f 1 #1 retainClosure (c0=<optimized out>, cp0=<optimized out>, r0=<optimized out>) at rts/RetainerProfile.c:1625 1625 if (isMember(r, retainerSetOfc)) (gdb) p c->header.prof.hp $4 = {rs = 0x5, ldvw = 5} (gdb) p flip $5 = 1 }}} The attached patch seems to fix this. Probably it can be made more efficient by using the fact that biographical profiling and retainer profiling are never turned on at the same time, but I'm not sure exactly how it should be implemented. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5909#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7480: Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr
by GHC 06 Feb '13

06 Feb '13

#7480: Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr -----------------------------+---------------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: patch Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Changes (by monoidal): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7480#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7663: consider free variables as well as parameters in inline discounts
by GHC 06 Feb '13

06 Feb '13

#7663: consider free variables as well as parameters in inline discounts -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The inliner assigns discount values for scrutinized parameters but not for scrutinized free variables. Experimenting with an aggressive lambda float at the end of the core2core pipeline identified a situation where (effectively) assigning discounts to free variables gives a performance boost. (The free variables become parameters during the float and hence are then assigned discounts.) For spectral/boyer2, doing the late lambda float and then simplifying results in a -7% improvement in allocation. Without the simplifications, the late lambda float alone does not change allocation: thus the lion's share of the -7% could be attained simply by assigning discounts to scrutinized free variables. For reference: the function in boyer2 that gets inlined is a join point that arises near the top of the worker for "Rewritefns.onewayunify". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7664: consider free variables as well as parameters in inline discounts
by GHC 06 Feb '13

06 Feb '13

#7664: consider free variables as well as parameters in inline discounts -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The inliner assigns discount values for scrutinized parameters but not for scrutinized free variables. Experimenting with an aggressive lambda float at the end of the core2core pipeline identified a situation where (effectively) assigning discounts to free variables gives a performance boost. (The free variables become parameters during the float and hence are then assigned discounts.) For spectral/boyer2, doing the late lambda float and then simplifying results in a -7% improvement in allocation. Without the simplifications, the late lambda float alone does not change allocation: thus the lion's share of the -7% could be attained simply by assigning discounts to scrutinized free variables. For reference: the function in boyer2 that gets inlined is a join point that arises near the top of the worker for "Rewritefns.onewayunify". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4