June 2013 - ghc-tickets

[GHC] #7923: Optimization for takeMVar/putMVar when MVar left empty
by GHC 15 Jun '13

15 Jun '13

#7923: Optimization for takeMVar/putMVar when MVar left empty ------------------------------------+--------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Right now, we always add an MVar to the mutable list when we takeMVar/putMVar. However, this is unnecessary when the MVar is left empty. This patch arranges that we don't add the MVar to the mutable list in those cases. I've validated the patch but haven't checked performance changes yet. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 5

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 15 Jun '13

15 Jun '13

#6063: GHC's build-time ld-flag checks are problematic --------------------------------------+------------------------------------- Reporter: parcs | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #4862 --------------------------------------+------------------------------------- Changes (by igloo): * owner: => thoughtpolice -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 15 Jun '13

15 Jun '13

#6063: GHC's build-time ld-flag checks are problematic --------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #4862 --------------------------------------+------------------------------------- Changes (by igloo): * owner: thoughtpolice => * status: patch => new -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 15 Jun '13

15 Jun '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Changes (by igloo): * owner: jstolarek => * status: patch => new Comment: I have the impression that these patches need some more polishing before they're ready to apply, so I'm reopening the ticket. Please let me know if that's wrong. Regarding the name of `sameMutableArray#`, I don't have a strong opinion. I suspect there are few users of the function, so personally I'd be inclined to use the most consistent names. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 15 Jun '13

15 Jun '13

#4001: Implement an atomic readMVar -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Comment(by ezyang): Performance impact with the extra queue: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- callback001 +0.1% +0.0% -1.7% -1.7% +0.0% callback002 +0.1% +0.0% -3.1% -3.1% +0.0% chan +0.1% +2.0% +2.6% +2.6% +3.8% sieve +0.1% +0.0% +0.0% +0.3% -13.0% threads001 +0.1% +0.0% +5.1% +5.2% +0.0% threads003 +0.1% +0.0% +1.0% +0.8% +0.0% threads006 +0.1% +0.0% +0.0% +0.0% +2.6% threads007 +0.1% +1.1% +1.3% +1.2% +0.0% -------------------------------------------------------------------------------- Min +0.1% +0.0% -3.1% -3.1% -13.0% Max +0.1% +2.0% +5.1% +5.2% +3.8% Geometric Mean +0.1% +0.4% +0.6% +0.6% -1.0% }}} Mysteriously enough threads001 doesn't create that many MVars, so it must be the added overhead in putMVar -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7956: ghci segfaults with -vN command-line options
by GHC 15 Jun '13

15 Jun '13

#7956: ghci segfaults with -vN command-line options -----------------------+---------------------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: ghci, -v0, segfault Os: MacOS X | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- Invoking ghci with the -vN options (-v0, -v1, -v2, -v3) segfaults. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7985: Allow openFile on unknown file type
by GHC 14 Jun '13

14 Jun '13

#7985: Allow openFile on unknown file type -----------------------------+---------------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- There should be an "unknown" file type, to allow for special file types to be opened without an exception. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 14 Jun '13

14 Jun '13

#4001: Implement an atomic readMVar -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Comment(by ezyang): I thought of a way to remove the extra queue: push reader threads onto the front of the ordinary queue, then modify putMVar to loop through the queue until it finds a taker. (The invariant is that reader threads are always in the front.) Unfortunately, this seems incompatible with arranging for the closure to be unlocked before the loop, since we won't know what the new head pointer for the MVar should be until we've finished traversing the queue. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 14 Jun '13

14 Jun '13

#4001: Implement an atomic readMVar -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Comment(by ezyang): It occurs to me that there is a problem with the current implementation, which is that we may do an unbounded amount of work while the spinlock for an MVar is taken out. Probably the right thing to do is arrange for the closure to be unlocked before we start spinning up threads. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 14 Jun '13

14 Jun '13

#4001: Implement an atomic readMVar -------------------------------------------+-------------------------------- Reporter: simonmar | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Moderate (less than a day) | Testcase: Blockedby: | Blocking: Related: | -------------------------------------------+-------------------------------- Changes (by ezyang): * owner: => ezyang Comment: On a whim, I decided to implement atomicReadMVar. Details: * Adds an extra word to the size of StgMVar; someone needs to find out how expensive this is. * Adds an extra memory dereference to putMVar/tryPutMVar, since they now need to check if there are any threads which are waiting on reads. Otherwise, it's implemented exactly as Simon described it. I still don't know if this is a good idea, but it does seem that a "wake all" semantics might be pretty useful for MVars. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4001#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0