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 @@
fileRTS 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.)
+
+
+
+
+