From d779cca065e2059d300928b0d547798f36afb073 Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Wed, 10 Dec 2008 16:45:57 +0000 Subject: [PATCH] Document new GC options -q1 and -qg --- docs/users_guide/runtime_control.xml | 74 ++++++++++++++++++++-------------- 1 file changed, 44 insertions(+), 30 deletions(-) diff --git a/docs/users_guide/runtime_control.xml b/docs/users_guide/runtime_control.xml index 94995b3..3170f09 100644 --- a/docs/users_guide/runtime_control.xml +++ b/docs/users_guide/runtime_control.xml @@ -298,38 +298,52 @@ - threads - RTS option + + RTS + option - [Default: 1] [new in GHC 6.10] Set the number - of threads to use for garbage collection. This option is - only accepted when the program was linked with the - option; see . - - The garbage collector is able to work in parallel when - given more than one OS thread. Experiments have shown - that this usually results in a performance improvement - given 3 cores or more; with 2 cores it may or may not be - beneficial, depending on the workload. Bigger heaps work - better with parallel GC, so set your - value high (3 or more times the maximum residency). Look - at the timing stats with to - see whether you're getting any benefit from parallel GC or - not. If you find parallel GC is - significantly slower (in elapsed - time) than sequential GC, please report it as a - bug. - - This value is set automatically when the - option is used, so the only reason to - use would be if you wanted to use a - different number of threads for GC than for execution. - For example, if your program is strictly single-threaded - but you still want to benefit from parallel GC, then it - might make sense to use rather than - . + [New in GHC 6.12.1] Disable the parallel GC. + The parallel GC is turned on automatically when parallel + execution is enabled with the option; + this option is available to turn it off if + necessary. + + Experiments have shown that parallel GC usually + results in a performance improvement given 3 cores or + more; with 2 cores it may or may not be beneficial, + depending on the workload. Bigger heaps work better with + parallel GC, so set your value high (3 + or more times the maximum residency). Look at the timing + stats with to see whether you're + getting any benefit from parallel GC or not. If you find + parallel GC is significantly slower + (in elapsed time) than sequential GC, please report it as + a bug. + + In GHC 6.10.1 it was possible to use a different + number of threads for GC than for execution, because the GC + used its own pool of threads. Now, the GC uses the same + threads as the mutator (for executing the program). + + + + + + + RTS + option + + + + [Default: 1] [New in GHC 6.12.1] + Enable the parallel GC only in + generation n and greater. + Parallel GC is often not worthwhile for collections in + generation 0 (the young generation), so it is enabled by + default only for collections in generation 1 (and higher, + if applicable). + -- 1.7.10.4