garbage collection for GHC, which means less compilation
time. If you use the <option>-Rghc-timing</option> option,
you'll get a garbage-collector report. (Again, you can use
- the cheap-and-nasty <option>+RTS -Sstderr -RTS</option>
+ the cheap-and-nasty <option>+RTS -S -RTS</option>
option to send the GC stats straight to standard
error.)</para>
</varlistentry>
<varlistentry>
- <term>Compile via C and crank up GCC:</term>
+ <term>Compile via LLVM:</term>
<listitem>
- <para>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.</para>
-
- <para>So, when we want very fast code, we use: <option>-O
- -fvia-C</option>.</para>
+ <para>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.</para>
</listitem>
</varlistentry>
<para>
“I think I have a space leak…” Re-run your program
-with <option>+RTS -Sstderr</option>, and remove all doubt! (You'll
+with <option>+RTS -S</option>, and remove all doubt! (You'll
see the heap usage get bigger and bigger…)
[Hmmm…this might be even easier with the
<option>-G1</option> RTS option; so… <command>./a.out +RTS
--Sstderr -G1</command>...]
+-S -G1</command>...]
<indexterm><primary>-G RTS option</primary></indexterm>
-<indexterm><primary>-Sstderr RTS option</primary></indexterm>
+<indexterm><primary>-S RTS option</primary></indexterm>
</para>
<para>
<!-- Emacs stuff:
;;; Local Variables: ***
- ;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
;;; End: ***
-->