Re: heap profiling

[Simon Marlow]

On 16/06/2010 14:04, Jesper Louis Andersen wrote:


Finally, you can tune the eden/nursery generation by providing +RTS
-A5m for instance. The default is 0.5 megabytes which I think is way
too low for most work. Increasing it blindly will hurt though as you
will hit L1/L2 cache limits and get worse performance.


Not sure I follow here - you say that 0.5MB is too low, and yet 
increasing it will hurt performance (I agree with you on the last point: 
in my experience most of the time increasing it does tend to make things 
worse).  OTOH there are programs where the 0.5MB default really hurts - 
the binary-trees benchmark on the shootout, for example.


If we could identify a useful set of heuristics to decide when it's a 
good idea to increase the nursery size, that would help.  I think the 
only way to get a real handle on this is to put together a comprehensive 
benchmark suite and test lots of different programs with different heap 
requirements, and on lots of different machines with different cache sizes.


Incedentally, GHC HEAD has a new flag +RTS -H, which increases the 
nursery size but without increasing the overall memory use (basically it 
uses the space left over after a copying major collection for the 
nursery).  This sometimes helps with programs that have large heaps, but 
not always.


Cheers,
Simon




My application has had problems with both retainer profiling and
(especially) biographical profiling - but whenever I try to make a
watered-down reproducible example the problem disappears. If you do
manage the get a reproducible bug going, I am interested in that
ticket.


So, the main question:

I have a program that runs some computation in a monad stack before
extracting the final result, a list, and passing it on.  When run
under the heap profiler, there's a huge spike in that phase, which I
think should be mostly bogus usage, since the final output is so
relatively small.  When I run under -hb I see big bands for LAG and
DRAG.


I would look at retainers. Or if you hold on to things you don't use
anymore rather than dropping the reference. In general, the heap
profiler is the way to go for removing space leak problems -



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

getting Core Haskell from GHC API with cross-module inlinings

[Roman Beslik]

Hi.
The following code compiles A.hs with GHC API:
{{{
import GHC
import Outputable
import DynFlags ( defaultDynFlags )
libdir = /usr/lib/ghc-6.12.1
targetFile = A.hs
main = defaultErrorHandler defaultDynFlags $ do
runGhc (Just libdir) $ do
dflags - fmap (\dflags - dflags {optLevel = 2}) 
getSessionDynFlags

setSessionDynFlags dflags
c - compileToCoreSimplified targetFile
print (showSDoc (ppr c))
}}}
A.hs: {{{
import Data.Maybe
main = print (show (maybe False (\_ - True) (Just False)))
}}}
When A.hs is compiled with GHC API, output contains a reference to 
'maybe'. When A.hs is compiled with ghc -O2 -ddump-simpl, 'maybe' is 
inlined and simplified. Why do outputs differ?


--
Best regards,
  Roman Beslik.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1

[Ian Lynagh]

On Thu, Jun 03, 2010 at 09:25:16PM -0400, Paul Jarc wrote:
 Ian Lynagh wrote:
  We are pleased to announce the first release candidate for GHC 6.12.3:
 
 There's a small build problem, also present in earlier 6.12 versions.
 The gzip program uses the $GZIP environment variable, which I have set
 in my environment.  This conflicts with the GZIP Makefile variable
 used in ghc.

Thanks for the report; fixed in 6.14.


Thanks
Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users