Re: [GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported

2009-05-29 Thread GHC 
#3259: A module-local combinator using Control.Parallel.par behaves differently
than when it's imported
-+--
Reporter:  blamario  |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.11   
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  x86   |  
-+--
Changes (by simonpj):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 OK so after talking to Simon I indeed moved the exposure of `lazy` into
 `CorePrep`.  That certainly fixes the bug.
 {{{
 Fri May 29 00:20:20 PDT 2009  simo...@microsoft.com
   * Fix Trac #3259: expose 'lazy' only after generating interface files
   Ignore-this: 3c762bda546981c4b4f01d28b8586ff8

   This patch fixes an insidious and long-standing bug in the way that
   parallelism is handled in GHC.  See Note [lazyId magic] in MkId.
 ...snip...
   The downside is that a little less optimisation may happen on programs
   that use 'lazy'.  And you'll only see this in the results -ddump-prep
   not in -ddump-simpl.  So KEEP AN EYE OUT (Simon and Satnam especially).
   Still, it should work properly now.  Certainly fixes #3259.

 M ./compiler/basicTypes/MkId.lhs -18 +23
 M ./compiler/coreSyn/CorePrep.lhs -2 +10
 M ./compiler/stranal/WorkWrap.lhs -10 +3
 }}}
 I have not added a test case, because I can't see a simple way to test it.
 But please do see if things improve.

 Do watch out for loss of optimisation as a result.  Simon and I do not
 think it'll be important, but we've been wrong before.

 For example, in your program you have way too many `lazy` calls:
 {{{
 parallelize a b = lazy a `par` (lazy b `pseq` (a, b))
 }}}
 Here the `lazy` calls are completely unnecessary, and indeed they (now)
 make the code a bit less efficient. Instead you can say
 {{{
 parallelize a b = a `par` (b `pseq` (a, b))
 }}}
 Thank you for identifying such an insidious bug.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3259#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported

2009-05-24 Thread GHC 
#3259: A module-local combinator using Control.Parallel.par behaves differently
than when it's imported
-+--
Reporter:  blamario  |  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.11  |   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Linux |   Architecture:  x86 
-+--
 There's a moderately long thr...@haskell-cafe discussing the problem at:

 http://www.haskell.org/pipermail/haskell-cafe/2009-May/061765.html

 I will attach the source files and the outputs of compilation with

 ghc-6.11.20090421 --make primes-test.hs -threaded -O2 -ddump-simpl

 on a 32-bit Ubuntu 2009.4.

 What appears to be happening is that GHC generates the call to function
 `parallelize' as though it was strict, even though the interface declares
 it as lazy, but only when the function is imported.

 The only proof of this, apart from the execution time, is this line of
 difference between the two -ddump-simpl outputs:

  $diff main.simpl imported.simpl
  ...
  223c232
   a_s1rs [ALWAYS Just L] :: GHC.Integer.Internals.Integer
  ---
   a_s1sV [ALWAYS Just S] :: GHC.Integer.Internals.Integer
  ...

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3259
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs