- ghc-tickets - Haskell.org

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

08 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: | --------------------------------------+------------------------------------- Comment(by dterei): I put a note in http://hackage.haskell.org/trac/ghc/wiki/Building/RunningNoFib and also in the README file about the dependency. I don't think we should otherwise include the actual dependency if that was your implication. Thanks morabbin! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

08 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: | --------------------------------------+------------------------------------- Comment(by morabbin): Not sure if this is the place to report this, but without {{{ cabal install html }}} `nofib-analyse` won't compile, as it uses `Text.Html`. Where is the correct place to put this dependency? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5793#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7675: Program lives on with dead main thread
by GHC 08 Feb '13

08 Feb '13

#7675: Program lives on with dead main thread -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control- Concurrent.html#g:13 says: In a standalone GHC program, only the main thread is required to terminate in order for the process to terminate. Thus all other forked threads will simply terminate at the same time as the main thread (the terminology for this kind of behaviour is "daemonic threads"). This isn't always true in ghc, as the following program demonstrates: {{{ % cat try.hs import Control.Concurrent import Control.Concurrent.STM import Control.Monad import System.Exit main :: IO () main = do x <- newTVarIO 0 forkIO $ forever $ do --atomically $ writeTVar x 42 --yield return () putStrLn "about to exit" exitSuccess putStrLn "dead" }}} {{{ % ghc -fforce-recomp try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try about to exit ^C^C }}} Instead of actually exiting, the program consumes 100% CPU despite the main thread being gone. The behavior is slightly different with `-threaded`: {{{ % ghc -fforce-recomp -threaded try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try ^C^C }}} Here it doesn't even execute the main thread. {{{ % ./try +RTS -N2 try: Using large values for -N is not allowed by default. Link with -rtsopts to allow full control. }}} I don't understand what's up with this. 2 isn't what I'd call "large". {{{ % ghc -fforce-recomp -threaded -rtsopts=all try.hs [1 of 1] Compiling Main ( try.hs, try.o ) Linking try ... % ./try +RTS -N2 about to exit }}} This version works as expected. Anyway, I'm not sure whether this is a bug in the RTS or in the documentation, but they clearly don't agree. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4429: Ability to specify the namespace in mkName
by GHC 07 Feb '13

07 Feb '13

#4429: Ability to specify the namespace in mkName ---------------------------------+------------------------------------------ Reporter: reinerp | Owner: reinerp Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Template Haskell | Version: 6.12.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * cc: andy.adamsmoran@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4429#comment:33> 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 JohnWiegley): * cc: johnw@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2959#comment:8> 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: | ---------------------------------+------------------------------------------ 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