#3061: GHC's GC default heap growth strategy is not as good as other runtimes
-----------------------------------------+----------------------------------
Reporter: dons | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Runtime System | Version: 6.10.1
Severity: normal | Resolution:
Keywords: performance, GC | Difficulty: Unknown
Testcase: yes | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-----------------------------------------+----------------------------------
Comment (by dons):
BTW, here's the ruling for the shootout:
http://alioth.debian.org/tracker/index.php?func=detail&aid=311528&group_id=30402&atid=411005
{{{
"For many language implementations the binary-trees programs are all about
GC and GC work can be evaded by setting a
larger initial heap, hinting that the heap will be in some size range,
controlling when GC happens etc
We've taken an arbitrary approach - just default settings for all language
implementations.
Maybe there's a better (rather than different arbitrary) approach?
Nothing persuasive has been suggested yet."
}}}
I'm out of ideas for making binary-trees parallelise better then :)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3061#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
