X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fruntime_control.xml;h=d8735e209df1f6ddd83d03d5ae93421756bb6a6e;hb=00fe691ba258b2d9c8d5d85a3dffc0224b426dd8;hp=e0dd420cab7cbbd4fd28af818800f8aa44e8ffe2;hpb=11f6f411b4a15b333423715b41b498f5f7745933;p=ghc-hetmet.git diff --git a/docs/users_guide/runtime_control.xml b/docs/users_guide/runtime_control.xml index e0dd420..d8735e2 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). + @@ -477,6 +491,10 @@ file RTS option + + + RTS option + These options produce runtime-system statistics, such as the amount of time spent executing the program and in the @@ -543,6 +561,27 @@ + You can also get this in a more future-proof, machine readable + format, with -t --machine-readable: + + + + [("bytes allocated", "36169392") + ,("num_GCs", "69") + ,("average_bytes_used", "603392") + ,("max_bytes_used", "1065272") + ,("num_byte_usage_samples", "2") + ,("peak_megabytes_allocated", "3") + ,("init_cpu_seconds", "0.00") + ,("init_wall_seconds", "0.00") + ,("mutator_cpu_seconds", "0.02") + ,("mutator_wall_seconds", "0.02") + ,("GC_cpu_seconds", "0.07") + ,("GC_wall_seconds", "0.07") + ] + + + If you use the -s flag then, when your program finishes, you will see something like this (the exact details will vary depending on what sort of RTS you have, e.g. @@ -992,7 +1031,90 @@ $ ./a.out +RTS --info ] The information is formatted such that it can be read as a - of type [(String, String)]. + of type [(String, String)]. Currently the following + fields are present: + + + + + GHC RTS + + Is this program linked against the GHC RTS? (Currently + the answer is always yes.) + + + + + GHC version + + The version of GHC used to compile this program. + + + + + RTS way + + The variant (“way”) of the runtime. Possible + values are rts (vanilla), + rts_thr (threaded runtime, i.e. linked using the + -threaded option) and rts_p + (profiling runtime, i.e. linked using the -prof + option). Other variants include t + (ticky-ticky profiling) and dyn (the RTS is + linked in dynamically, i.e. a shared library, rather than statically + linked into the executable itself). + + + + + Target platform + + This is the platform the program is compiled to run on. + + + + + Build platform + + This is the platform where the program was compiled + from. (That is, the target platform of GHC itself.) Ordinarily + this is identical to the target platform. (It could potentially + be different if cross-compiling.) + + + + + Host platform + + This is the platform where GHC itself was compiled. + Again, this would normally be identical to the build and + target platforms. + + + + + Compiler unregistered + + Was this program compiled with an “unregistered” + version of GHC? (I.e., a version of GHC that has no platform-specific + optimisations compiled in, usually because this is a currently + unsupported platform.) This value will usually be no, unless you're + using an experimental build of GHC. + + + + + Tables next to code + + Putting info tables directly next to entry code is a useful + performance optimisation that is not available on all platforms. + This field tells you whether the program has been compiled with + this optimisation. (Usually yes, except on unusual platforms.) + + + + +