X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fdocs%2Fusers_guide%2Fsooner.sgml;fp=ghc%2Fdocs%2Fusers_guide%2Fsooner.sgml;h=e183562aa3361c3e826110bb02e858b9efa207ba;hb=57ad929d509b5f1b5c5ad510eb2831163f2071fa;hp=63ede497d09da58e674e61145db33c1f841b0ca7;hpb=67909e79eea6f0e9b2350d01d1322fde587bcc64;p=ghc-hetmet.git diff --git a/ghc/docs/users_guide/sooner.sgml b/ghc/docs/users_guide/sooner.sgml index 63ede49..e183562 100644 --- a/ghc/docs/users_guide/sooner.sgml +++ b/ghc/docs/users_guide/sooner.sgml @@ -16,7 +16,7 @@ Please advise us of other ``helpful hints'' that should go here! -Don't use -O or (especially) -O2: +Don't use or (especially) : By using them, you are telling GHC that you are willing to suffer @@ -24,7 +24,7 @@ longer compilation times for better-quality code. -GHC is surprisingly zippy for normal compilations without -O! +GHC is surprisingly zippy for normal compilations without ! @@ -34,8 +34,8 @@ GHC is surprisingly zippy for normal compilations without -O! Within reason, more memory for heap space means less garbage collection for GHC, which means less compilation time. If you use -the -Rgc-stats option, you'll get a garbage-collector report. -(Again, you can use the cheap-and-nasty -optCrts-Sstderr option to +the option, you'll get a garbage-collector report. +(Again, you can use the cheap-and-nasty option to send the GC stats straight to standard error.) @@ -47,13 +47,13 @@ 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>-M<size> option option, e.g.: ghc -c -O --M1024m Foo.hs. +-M<size> option option, e.g.: ghc -c -O +-M1024m Foo.hs. Increasing the default allocation area size used by the compiler's RTS -might also help: use the -A<size>-A<size> option +might also help: use the -A<size> option option. @@ -71,7 +71,7 @@ As soon as GHC plus its ``fellow citizens'' (other processes on your machine) start using more than the real memory on your machine, and the machine starts ``thrashing,'' the party is over. Compile times will be worse than terrible! Use something -like the csh-builtin time command to get a report on how many page +like the csh-builtin time command to get a report on how many page faults you're getting. @@ -99,7 +99,7 @@ your disks directly mounted. -Don't derive/use Read unnecessarily: +Don't derive/use Read unnecessarily: It's ugly and slow. @@ -123,20 +123,20 @@ to correct it. The parts of the compiler that seem most prone to wandering off for a long time are the abstract interpreters (strictness and update analysers). You can turn these off individually with --fno-strictness-fno-strictness anti-option and --fno-update-analysis.-fno-update-analysis anti-option +-fno-strictness anti-option and +.-fno-update-analysis anti-option To figure out which part of the compiler is badly behaved, the --dshow-passes-dshow-passes option option is your +-dshow-passes option 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-fvia-C option +allocator to founder. Bring on -fvia-C option (not that GCC will be that quick about it, either). @@ -145,7 +145,7 @@ allocator to founder. Bring on -fvia-C-f Avoid the consistency-check on linking: -Use -no-link-chk-no-link-chk; saves effort. This is +Use -no-link-chk; saves effort. This is probably safe in a I-only-compile-things-one-way setup. @@ -211,16 +211,16 @@ faster''… -Optimise, using -O or -O2: +Optimise, using or : This is the most basic way to make your program go faster. Compilation time will be slower, -especially with -O2. +especially with . -At present, -O2 is nearly indistinguishable from -O. +At present, is nearly indistinguishable from . @@ -228,7 +228,7 @@ At present, -O2 is nearly indistinguishable from -O< Compile via C and crank up GCC: -Even with -O, GHC tries to +Even with , GHC tries to use a native-code generator, if available. But 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 @@ -236,7 +236,7 @@ allocation, etc. -So, when we want very fast code, we use: -O -fvia-C -O2-for-C. +So, when we want very fast code, we use: . @@ -258,12 +258,12 @@ loop. How can you squash it? Signatures are the basic trick; putting them on exported, top-level functions is good software-engineering practice, anyway. (Tip: using --fwarn-missing-signatures-fwarn-missing-signatures +-fwarn-missing-signatures option can help enforce good signature-practice). -The automatic specialisation of overloaded functions (with -O) +The automatic specialisation of overloaded functions (with ) should take care of overloaded local and/or unexported functions. @@ -377,22 +377,22 @@ Don't guess—look it up. Look for your function in the interface file, then for the third field in the pragma; it should say _S_ <string>. The <string> -gives the strictness of the function's arguments. L is lazy -(bad), S and E are strict (good), P is ``primitive'' (good), -U(...) is strict and -``unpackable'' (very good), and A is absent (very good). +gives the strictness of the function's arguments. L is lazy +(bad), S and E are strict (good), P is ``primitive'' (good), +U(...) is strict and +``unpackable'' (very good), and A is absent (very good). -For an ``unpackable'' U(...) argument, the info inside +For an ``unpackable'' U(...) argument, the info inside tells the strictness of its components. So, if the argument is a -pair, and it says U(AU(LSS)), that means ``the first component of the +pair, and it says U(AU(LSS)), that means ``the first component of the pair isn't used; the second component is itself unpackable, with three components (lazy in the first, strict in the second \& third).'' -If the function isn't exported, just compile with the extra flag -ddump-simpl; +If the function isn't exported, just compile with the extra flag ; next to the signature for any binder, it will print the self-same pragmatic information as would be put in an interface file. (Besides, Core syntax is fun to look at!) @@ -431,7 +431,7 @@ they are not exported. (The form in which GHC manipulates your code.) Just run your -compilation with -ddump-simpl (don't forget the -O). +compilation with (don't forget the ). @@ -454,7 +454,7 @@ types. -Use _ccall_s (a GHC extension) to plug into fast libraries: +Use _ccall_s (a GHC extension) to plug into fast libraries: This may take real work, but… There exist piles of @@ -496,11 +496,11 @@ true on a 64-bit machine. Use a bigger heap! -If your program's GC stats (-S-S RTS option RTS option) +If your program's GC stats (-S RTS option RTS option) indicate that it's doing lots of garbage-collection (say, more than 20% of execution time), more memory might help—with the --M<size>-M<size> RTS option or --A<size>-A<size> RTS option RTS options (see +-M<size> RTS option or +-A<size> RTS option RTS options (see ). @@ -521,7 +521,7 @@ indicate that it's doing lots of garbage-collection (say, more than Decrease the ``go-for-it'' threshold for unfolding smallish expressions. Give a --funfolding-use-threshold0-funfolding-use-threshold0 +-funfolding-use-threshold0 option option for the extreme case. (``Only unfoldings with zero cost should proceed.'') Warning: except in certain specialiised cases (like Happy parsers) this is likely to actually @@ -530,7 +530,7 @@ generally enables extra simplifying optimisations to be performed. -Avoid Read. +Avoid Read. @@ -551,10 +551,10 @@ Use strip on your executables. ``I think I have a space leak…'' Re-run your program with -+RTS -Sstderr,-Sstderr RTS option and remove all doubt! +,-Sstderr RTS option and remove all doubt! (You'll see the heap usage get bigger and bigger…) [Hmmm…this -might be even easier with the -F2s-F2s RTS option RTS -option; so… ./a.out +RTS -Sstderr -F2s...] +might be even easier with the -F2s RTS option RTS +option; so… ./a.out +RTS -Sstderr -F2s...]