October 2013 - ghc-tickets

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 08 Oct '13

08 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Interesting - I hadn't realised that the main thread being bound could affect the performance of ordinary parallel programs too. I'm very tempted to change the main thread to be non-bound. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 08 Oct '13

08 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): I also think it's worth noting that with the above change to `nofib/parallel/ray` applied, `yieldThread()` could be made a no-op and the runtime of the program does not change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 07 Oct '13

07 Oct '13

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, loops, Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2387,#1600 -------------------------------------+------------------------------------- Comment (by simonpj): In fact it's orthogonal to do with loopification, which does not affect allocation. Its to do with nested CPR analysis, which I'm longing to do but keep getting diverted. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8047: Implement line-number %-substitution for prompt-string
by GHC 07 Oct '13

07 Oct '13

#8047: Implement line-number %-substitution for prompt-string ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, GHCi supports the following `%`-interpolations: > `:set prompt prompt` > > Sets the string to be used as the prompt in GHCi. Inside prompt, the sequence %s is replaced by the names of the modules currently in scope, and %% is replaced by %. If prompt starts with " then it is parsed as a Haskell String; otherwise it is treated as a literal string. The attached patch implements the `%l` variable, which gets replaced by the current line number of the shown prompt. The motivation being, that compiler messages refer to interactively entered bindings by the line number when they were defined, which are a bit hard to keep track of, e.g.: {{{ λ> :set prompt "\955:%l> " λ:3> let x = () x :: () λ:4> let x = ((),()) x :: ((), ()) λ:5> print xx <interactive>:5:7: Not in scope: ‛xx’ Perhaps you meant ‛x’ (line 4) λ:6> :info x x :: ((), ()) -- Defined at <interactive>:4:5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] Batch modify: #8047
by GHC 07 Oct '13

07 Oct '13

Batch modification to #8047 by hvr: Action: reopen -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci
by GHC 07 Oct '13

07 Oct '13

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ rwbarton@adjunction:~/dist/ghc/libraries/base/tests$ echo main | ~/dist/ghc/inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --interactive -v0 -ignore-dot-ghci tup001d.hs <interactive>: internal error: interpretBCO: hit a CASEFAIL (GHC version 7.7.20130928 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} This causes libraries/base test `tup001` to fail in the same way with WAY=ghci, because the derived instance of Eq for enumeration-like types of more than 10 constructors does something like `x == y = tagToEnum# (getTag x ==# getTag y)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8417: Pattern matching on OverloadedLists is erratic
by GHC 07 Oct '13

07 Oct '13

#8417: Pattern matching on OverloadedLists is erratic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider {{{ λ> :set -XOverloadedLists λ> :t \[True] -> 'a' \[True] -> 'a' :: (GHC.Exts.IsList l, GHC.Exts.Item l ~ Bool) => l -> Char λ> :t \[not] -> 'a' \[not] -> 'a' :: GHC.Exts.IsList l => l -> Char }}} The first type is expected, but the second one should include `GHC.Exts.Item l ~ Bool -> Bool` and `Eq (Bool -> Bool)`. Currently e.g. `(\[not] -> True) [id]` evaluates to `True`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 07 Oct '13

07 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): > I noticed that if I change nofib/parallel/ray to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance? It could be because main runs in a bound thread. Why that makes a huge difference I'm not sure (more context switching?), but that's a likely cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 07 Oct '13

07 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * cc: simonmar (added) Comment: I noticed that if I change `nofib/parallel/ray` to do its work in a separate thread (see diff), that this "last core slowdown" completely vanishes. Can anybody explain this massive variance? {{{ #!diff diff --git a/parallel/ray/Main.lhs b/parallel/ray/Main.lhs index a1a72e6..bcd020f 100644 --- a/parallel/ray/Main.lhs +++ b/parallel/ray/Main.lhs @@ -5,10 +5,15 @@ Michaelson for SML, converted to (parallel) Haskell by Kevin Hammond! > import Control.Parallel > import Control.Parallel.Strategies (Strategy, withStrategy, rseq, parBuffer) > import System.Environment +> import Control.Concurrent > main = do -> [detail] <- fmap (map read) getArgs -> putStr (top detail 10.0 7.0 6.0 sc) +> v <- newEmptyMVar +> forkIO $ do +> [detail] <- fmap (map read) getArgs +> putStr (top detail 10.0 7.0 6.0 sc) +> putMVar v () +> takeMVar v > type Coord = (Double,Double,Double) }}} Before patch: {{{ parcs@wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 94255.765778 task-clock # 6.343 CPUs utilized 2,686,596 context-switches # 0.029 M/sec 6,592 CPU-migrations # 0.000 M/sec 2,243 page-faults # 0.000 M/sec 338,901,646,069 cycles # 3.596 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 264,852,020,580 instructions # 0.78 insns per cycle 48,676,712,628 branches # 516.432 M/sec 1,114,612,869 branch-misses # 2.29% of all branches 14.859603166 seconds time elapsed }}} After patch: {{{ parcs@wolfgang:~/ghc/nofib/parallel/ray$ perf stat ./ray 3000 +RTS -N > /dev/null Performance counter stats for './ray 3000 +RTS -N': 65701.145514 task-clock # 7.919 CPUs utilized 41,217 context-switches # 0.001 M/sec 101 CPU-migrations # 0.000 M/sec 2,274 page-faults # 0.000 M/sec 242,921,371,383 cycles # 3.697 GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 216,526,115,297 instructions # 0.89 insns per cycle 39,079,392,369 branches # 594.805 M/sec 840,462,837 branch-misses # 2.15% of all branches 8.296947901 seconds time elapsed }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 07 Oct '13

07 Oct '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by cjwatson): Things have moved on quite a bit since I last checked, but that ticket does look essentially the same as this one. When I last looked, though, GHCi wasn't actually using the relevant part of libffi in the newExecConItbl path, and I still can't find anything that would do this. Am I missing something here or is bgamari? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0