X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fsooner.xml;h=eb85878a0d4339b7c6dbc2f155f9e6c86d2d1f4b;hb=a0f6d307b097bd788e181434a4d9b7fdd56a6c6b;hp=ec1bb3dc01807754a54729973db9c431e71d4b06;hpb=9744a9c7b9ca160c0dc3332c4c8a289e6a8fce6e;p=ghc-hetmet.git
diff --git a/docs/users_guide/sooner.xml b/docs/users_guide/sooner.xml
index ec1bb3d..eb85878 100644
--- a/docs/users_guide/sooner.xml
+++ b/docs/users_guide/sooner.xml
@@ -32,25 +32,18 @@ should go here!
garbage collection for GHC, which means less compilation
time. If you use the option,
you'll get a garbage-collector report. (Again, you can use
- the cheap-and-nasty
+ the cheap-and-nasty
option to send the GC stats straight to standard
error.)
If it says you're using more than 20% of total
- time in garbage collecting, then more memory would
- help.
-
- If the heap size is approaching the maximum (64M by
- default), and you have lots of memory, try increasing the
- maximum with the
- -M<size>
- option option, e.g.: ghc -c
- -O -M1024m Foo.hs.
-
- Increasing the default allocation area size used by
+ time in garbage collecting, then more memory might
+ help: use the
+
+ option. Increasing the default allocation area size used by
the compiler's RTS might also help: use the
- -A<size>
- option option.
+ -A<size>
+ RTS option option.
If GHC persists in being a bad memory citizen, please
report it as a bug.
@@ -101,48 +94,13 @@ should go here!
GHC compiles some program constructs slowly:
- Deeply-nested list comprehensions seem to be one such;
- in the past, very large constant tables were bad,
- too.
-
We'd rather you reported such behaviour as a bug, so
that we can try to correct it.
- The part of the compiler that is occasionally prone to
- wandering off for a long time is the strictness analyser.
- You can turn this off individually with
- .
- -fno-strictness
- anti-option
-
To figure out which part of the compiler is badly
behaved, the
option is your friend.
-
- If your module has big wads of constant data, GHC may
- produce a huge basic block that will cause the native-code
- generator's register allocator to founder. Bring on
- -fvia-C
- option (not that GCC will be that
- quick about it, either).
-
-
-
-
- Explicit import declarations:
-
- Instead of saying import Foo, say
- import Foo (...stuff I want...) You can
- get GHC to tell you the minimal set of required imports by
- using the option
- (see ).
-
- Truthfully, the reduction on compilation time will be
- very small. However, judicious use of
- import declarations can make a program
- easier to understand, so it may be a good idea
- anyway.
@@ -194,15 +152,23 @@ should go here!
+ Compile via LLVM:
+
+ The LLVM code generator can sometimes do a far better job
+ at producing fast code then either the native code generator
+ or the C code generator. This is not universal and depends
+ on the code. Numeric heavy code seems to show the best
+ improvement when compiled via LLVM.
+
+
+
+ Compile via C and crank up GCC:The native code-generator is designed to be quick, not
mind-bogglingly clever. Better to let GCC have a go, as it
tries much harder on register allocation, etc.
- At the moment, if you turn on you
- get GCC instead. This may change in the future.
-
So, when we want very fast code, we use: .
@@ -556,13 +522,13 @@ Use strip on your executables.
“I think I have a space leak…” Re-run your program
-with , and remove all doubt! (You'll
+with , and remove all doubt! (You'll
see the heap usage get bigger and bigger…)
[Hmmm…this might be even easier with the
RTS option; so… ./a.out +RTS
--Sstderr -G1...]
+-S -G1...]
-G RTS option
--Sstderr RTS option
+-S RTS option
@@ -584,7 +550,6 @@ be required).