#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):
Replying to [comment:1 simonmar]:
> So you're not allowed to use GC settings in the shootout? I think this
benchmark is pathological for our default GC settings. The reason is that
we use a small fixed-size allocation area, which is usually good for cache
behaviour, but in this benchmark when we get to the larger tree sizes, we
always GC before the tree has been constructed, and the GC therefore has
to copy the tree, possibly multiple times. In fact this is very similar
to a standard GC benchmark that we use.
>
Currently you can't, no. But the question is why can the other languages
do better without the hint (e.g. Java is twice as fast, though on single
core we're much better)? I wrote more about this benchmark in a blog post:
http://donsbot.wordpress.com/2009/03/04/playing-with-ghcs-parallel-
runtime/
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3061#comment:3>
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
