docs/users_guide/sooner.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <chapter id="sooner-faster-quicker">
   3 <title>Advice on: sooner, faster, smaller, thriftier</title>
   4
   5 <para>Please advise us of other &ldquo;helpful hints&rdquo; that
   6 should go here!</para>
   7
   8 <sect1 id="sooner">
   9 <title>Sooner: producing a program more quickly
  10 </title>
  11
  12 <indexterm><primary>compiling faster</primary></indexterm>
  13 <indexterm><primary>faster compiling</primary></indexterm>
  14
  15     <variablelist>
  16       <varlistentry>
  17         <term>Don't use <option>-O</option> or (especially) <option>-O2</option>:</term>
  18         <listitem>
  19           <para>By using them, you are telling GHC that you are
  20           willing to suffer longer compilation times for
  21           better-quality code.</para>
  22
  23           <para>GHC is surprisingly zippy for normal compilations
  24           without <option>-O</option>!</para>
  25         </listitem>
  26       </varlistentry>
  27
  28       <varlistentry>
  29         <term>Use more memory:</term>
  30         <listitem>
  31           <para>Within reason, more memory for heap space means less
  32           garbage collection for GHC, which means less compilation
  33           time.  If you use the <option>-Rghc-timing</option> option,
  34           you'll get a garbage-collector report.  (Again, you can use
  35           the cheap-and-nasty <option>+RTS -S -RTS</option>
  36           option to send the GC stats straight to standard
  37           error.)</para>
  38
  39           <para>If it says you're using more than 20&percnt; of total
  40           time in garbage collecting, then more memory might
  41           help: use the
  42           <option>-H&lt;size&gt;</option><indexterm><primary><option>-H</option></primary></indexterm>
  43           option.  Increasing the default allocation area size used by
  44           the compiler's RTS might also help: use the
  45           <option>+RTS -A&lt;size&gt; -RTS</option><indexterm><primary>-A&lt;size&gt;
  46           RTS option</primary></indexterm> option.</para>
  47
  48           <para>If GHC persists in being a bad memory citizen, please
  49           report it as a bug.</para>
  50         </listitem>
  51       </varlistentry>
  52
  53       <varlistentry>
  54         <term>Don't use too much memory!</term>
  55         <listitem>
  56           <para>As soon as GHC plus its &ldquo;fellow citizens&rdquo;
  57           (other processes on your machine) start using more than the
  58           <emphasis>real memory</emphasis> on your machine, and the
  59           machine starts &ldquo;thrashing,&rdquo; <emphasis>the party
  60           is over</emphasis>.  Compile times will be worse than
  61           terrible!  Use something like the csh-builtin
  62           <command>time</command> command to get a report on how many
  63           page faults you're getting.</para>
  64
  65           <para>If you don't know what virtual memory, thrashing, and
  66           page faults are, or you don't know the memory configuration
  67           of your machine, <emphasis>don't</emphasis> try to be clever
  68           about memory use: you'll just make your life a misery (and
  69           for other people, too, probably).</para>
  70         </listitem>
  71       </varlistentry>
  72
  73       <varlistentry>
  74         <term>Try to use local disks when linking:</term>
  75         <listitem>
  76           <para>Because Haskell objects and libraries tend to be
  77           large, it can take many real seconds to slurp the bits
  78           to/from a remote filesystem.</para>
  79
  80           <para>It would be quite sensible to
  81           <emphasis>compile</emphasis> on a fast machine using
  82           remotely-mounted disks; then <emphasis>link</emphasis> on a
  83           slow machine that had your disks directly mounted.</para>
  84         </listitem>
  85       </varlistentry>
  86
  87       <varlistentry>
  88         <term>Don't derive/use <function>Read</function> unnecessarily:</term>
  89         <listitem>
  90           <para>It's ugly and slow.</para>
  91         </listitem>
  92       </varlistentry>
  93
  94       <varlistentry>
  95         <term>GHC compiles some program constructs slowly:</term>
  96         <listitem>
  97           <para>We'd rather you reported such behaviour as a bug, so
  98           that we can try to correct it.</para>
  99
 100           <para>To figure out which part of the compiler is badly
 101           behaved, the
 102           <option>-v2</option><indexterm><primary><option>-v</option></primary>
 103           </indexterm> option is your friend.</para>
 104         </listitem>
 105       </varlistentry>
 106     </variablelist>
 107   </sect1>
 108
 109   <sect1 id="faster">
 110     <title>Faster: producing a program that runs quicker</title>
 111
 112     <indexterm><primary>faster programs, how to produce</primary></indexterm>
 113
 114     <para>The key tool to use in making your Haskell program run
 115     faster are GHC's profiling facilities, described separately in
 116     <xref linkend="profiling"/>.  There is <emphasis>no
 117     substitute</emphasis> for finding where your program's time/space
 118     is <emphasis>really</emphasis> going, as opposed to where you
 119     imagine it is going.</para>
 120
 121     <para>Another point to bear in mind: By far the best way to
 122     improve a program's performance <emphasis>dramatically</emphasis>
 123     is to use better algorithms.  Once profiling has thrown the
 124     spotlight on the guilty time-consumer(s), it may be better to
 125     re-think your program than to try all the tweaks listed below.</para>
 126
 127     <para>Another extremely efficient way to make your program snappy
 128     is to use library code that has been Seriously Tuned By Someone
 129     Else.  You <emphasis>might</emphasis> be able to write a better
 130     quicksort than the one in <literal>Data.List</literal>, but it
 131     will take you much longer than typing <literal>import
 132     Data.List</literal>.</para>
 133
 134     <para>Please report any overly-slow GHC-compiled programs.  Since
 135     GHC doesn't have any credible competition in the performance
 136     department these days it's hard to say what overly-slow means, so
 137     just use your judgement!  Of course, if a GHC compiled program
 138     runs slower than the same program compiled with NHC or Hugs, then
 139     it's definitely a bug.</para>
 140
 141     <variablelist>
 142       <varlistentry>
 143         <term>Optimise, using <option>-O</option> or <option>-O2</option>:</term>
 144         <listitem>
 145           <para>This is the most basic way to make your program go
 146           faster.  Compilation time will be slower, especially with
 147           <option>-O2</option>.</para>
 148
 149           <para>At present, <option>-O2</option> is nearly
 150           indistinguishable from <option>-O</option>.</para>
 151         </listitem>
 152       </varlistentry>
 153
 154       <varlistentry>
 155         <term>Compile via LLVM:</term>
 156         <listitem>
 157                 <para>The LLVM code generator can sometimes do a far better job
 158                             at producing fast code then either the native code generator
 159                                         or the C code generator. This is not universal and depends
 160                                         on the code. Numeric heavy code seems to show the best
 161                                         improvement when compiled via LLVM.</para>
 162         </listitem>
 163       </varlistentry>
 164
 165       <varlistentry>
 166         <term>Compile via C and crank up GCC:</term>
 167         <listitem>
 168           <para>The native code-generator is designed to be quick, not
 169           mind-bogglingly clever.  Better to let GCC have a go, as it
 170           tries much harder on register allocation, etc.</para>
 171
 172           <para>So, when we want very fast code, we use: <option>-O
 173           -fvia-C</option>.</para>
 174         </listitem>
 175       </varlistentry>
 176
 177       <varlistentry>
 178         <term>Overloaded functions are not your friend:</term>
 179         <listitem>
 180           <para>Haskell's overloading (using type classes) is elegant,
 181           neat, etc., etc., but it is death to performance if left to
 182           linger in an inner loop.  How can you squash it?</para>
 183
 184           <variablelist>
 185             <varlistentry>
 186               <term>Give explicit type signatures:</term>
 187               <listitem>
 188                 <para>Signatures are the basic trick; putting them on
 189                 exported, top-level functions is good
 190                 software-engineering practice, anyway.  (Tip: using
 191                 <option>-fwarn-missing-signatures</option><indexterm><primary>-fwarn-missing-signatures
 192                 option</primary></indexterm> can help enforce good
 193                 signature-practice).</para>
 194
 195                 <para>The automatic specialisation of overloaded
 196                 functions (with <option>-O</option>) should take care
 197                 of overloaded local and/or unexported functions.</para>
 198               </listitem>
 199             </varlistentry>
 200
 201             <varlistentry>
 202               <term>Use <literal>SPECIALIZE</literal> pragmas:</term>
 203               <listitem>
 204                 <indexterm><primary>SPECIALIZE pragma</primary></indexterm>
 205                 <indexterm><primary>overloading, death to</primary></indexterm>
 206
 207                 <para>Specialize the overloading on key functions in
 208                 your program.  See <xref linkend="specialize-pragma"/>
 209                 and <xref linkend="specialize-instance-pragma"/>.</para>
 210               </listitem>
 211             </varlistentry>
 212
 213             <varlistentry>
 214               <term>&ldquo;But how do I know where overloading is creeping in?&rdquo;:</term>
 215               <listitem>
 216                 <para>A low-tech way: grep (search) your interface
 217                 files for overloaded type signatures.  You can view
 218                 interface files using the
 219                 <option>--show-iface</option> option (see <xref
 220                 linkend="hi-options"/>).
 221
 222 <programlisting>
 223 % ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=&#62;'
 224 </programlisting>
 225 </para>
 226               </listitem>
 227             </varlistentry>
 228           </variablelist>
 229         </listitem>
 230       </varlistentry>
 231
 232       <varlistentry>
 233         <term>Strict functions are your dear friends:</term>
 234         <listitem>
 235           <para>and, among other things, lazy pattern-matching is your
 236           enemy.</para>
 237
 238           <para>(If you don't know what a &ldquo;strict
 239           function&rdquo; is, please consult a functional-programming
 240           textbook.  A sentence or two of explanation here probably
 241           would not do much good.)</para>
 242
 243           <para>Consider these two code fragments:
 244
 245 <programlisting>
 246 f (Wibble x y) =  ... # strict
 247
 248 f arg = let { (Wibble x y) = arg } in ... # lazy
 249 </programlisting>
 250
 251            The former will result in far better code.</para>
 252
 253           <para>A less contrived example shows the use of
 254           <literal>cases</literal> instead of <literal>lets</literal>
 255           to get stricter code (a good thing):
 256
 257 <programlisting>
 258 f (Wibble x y)  # beautiful but slow
 259   = let
 260         (a1, b1, c1) = unpackFoo x
 261         (a2, b2, c2) = unpackFoo y
 262     in ...
 263
 264 f (Wibble x y)  # ugly, and proud of it
 265   = case (unpackFoo x) of { (a1, b1, c1) -&#62;
 266     case (unpackFoo y) of { (a2, b2, c2) -&#62;
 267     ...
 268     }}
 269 </programlisting>
 270
 271           </para>
 272         </listitem>
 273       </varlistentry>
 274
 275       <varlistentry>
 276         <term>GHC loves single-constructor data-types:</term>
 277         <listitem>
 278           <para>It's all the better if a function is strict in a
 279           single-constructor type (a type with only one
 280           data-constructor; for example, tuples are single-constructor
 281           types).</para>
 282         </listitem>
 283       </varlistentry>
 284
 285       <varlistentry>
 286         <term>Newtypes are better than datatypes:</term>
 287         <listitem>
 288           <para>If your datatype has a single constructor with a
 289           single field, use a <literal>newtype</literal> declaration
 290           instead of a <literal>data</literal> declaration.  The
 291           <literal>newtype</literal> will be optimised away in most
 292           cases.</para>
 293         </listitem>
 294       </varlistentry>
 295
 296       <varlistentry>
 297         <term>&ldquo;How do I find out a function's strictness?&rdquo;</term>
 298         <listitem>
 299           <para>Don't guess&mdash;look it up.</para>
 300
 301           <para>Look for your function in the interface file, then for
 302           the third field in the pragma; it should say
 303           <literal>&lowbar;&lowbar;S &lt;string&gt;</literal>.  The
 304           <literal>&lt;string&gt;</literal> gives the strictness of
 305           the function's arguments.  <function>L</function> is lazy
 306           (bad), <function>S</function> and <function>E</function> are
 307           strict (good), <function>P</function> is
 308           &ldquo;primitive&rdquo; (good), <function>U(...)</function>
 309           is strict and &ldquo;unpackable&rdquo; (very good), and
 310           <function>A</function> is absent (very good).</para>
 311
 312           <para>For an &ldquo;unpackable&rdquo;
 313           <function>U(...)</function> argument, the info inside tells
 314           the strictness of its components.  So, if the argument is a
 315           pair, and it says <function>U(AU(LSS))</function>, that
 316           means &ldquo;the first component of the pair isn't used; the
 317           second component is itself unpackable, with three components
 318           (lazy in the first, strict in the second \&#38;
 319           third).&rdquo;</para>
 320
 321           <para>If the function isn't exported, just compile with the
 322           extra flag <option>-ddump-simpl</option>; next to the
 323           signature for any binder, it will print the self-same
 324           pragmatic information as would be put in an interface file.
 325           (Besides, Core syntax is fun to look at!)</para>
 326         </listitem>
 327       </varlistentry>
 328
 329       <varlistentry>
 330         <term>Force key functions to be <literal>INLINE</literal>d (esp. monads):</term>
 331         <listitem>
 332           <para>Placing <literal>INLINE</literal> pragmas on certain
 333           functions that are used a lot can have a dramatic effect.
 334           See <xref linkend="inline-pragma"/>.</para>
 335         </listitem>
 336       </varlistentry>
 337
 338       <varlistentry>
 339         <term>Explicit <literal>export</literal> list:</term>
 340         <listitem>
 341           <para>If you do not have an explicit export list in a
 342           module, GHC must assume that everything in that module will
 343           be exported.  This has various pessimising effects.  For
 344           example, if a bit of code is actually
 345           <emphasis>unused</emphasis> (perhaps because of unfolding
 346           effects), GHC will not be able to throw it away, because it
 347           is exported and some other module may be relying on its
 348           existence.</para>
 349
 350           <para>GHC can be quite a bit more aggressive with pieces of
 351           code if it knows they are not exported.</para>
 352         </listitem>
 353       </varlistentry>
 354
 355       <varlistentry>
 356         <term>Look at the Core syntax!</term>
 357         <listitem>
 358           <para>(The form in which GHC manipulates your code.)  Just
 359           run your compilation with <option>-ddump-simpl</option>
 360           (don't forget the <option>-O</option>).</para>
 361
 362           <para>If profiling has pointed the finger at particular
 363           functions, look at their Core code.  <literal>lets</literal>
 364           are bad, <literal>cases</literal> are good, dictionaries
 365           (<literal>d.&lt;Class&gt;.&lt;Unique&gt;</literal>) &lsqb;or
 366           anything overloading-ish&rsqb; are bad, nested lambdas are
 367           bad, explicit data constructors are good, primitive
 368           operations (e.g., <literal>eqInt&num;</literal>) are
 369           good,&hellip;</para>
 370         </listitem>
 371       </varlistentry>
 372
 373       <varlistentry>
 374         <term>Use strictness annotations:</term>
 375         <listitem>
 376           <para>Putting a strictness annotation ('!') on a constructor
 377           field helps in two ways: it adds strictness to the program,
 378           which gives the strictness analyser more to work with, and
 379           it might help to reduce space leaks.</para>
 380
 381           <para>It can also help in a third way: when used with
 382           <option>-funbox-strict-fields</option> (see <xref
 383           linkend="options-f"/>), a strict field can be unpacked or
 384           unboxed in the constructor, and one or more levels of
 385           indirection may be removed.  Unpacking only happens for
 386           single-constructor datatypes (<literal>Int</literal> is a
 387           good candidate, for example).</para>
 388
 389           <para>Using <option>-funbox-strict-fields</option> is only
 390           really a good idea in conjunction with <option>-O</option>,
 391           because otherwise the extra packing and unpacking won't be
 392           optimised away.  In fact, it is possible that
 393           <option>-funbox-strict-fields</option> may worsen
 394           performance even <emphasis>with</emphasis>
 395           <option>-O</option>, but this is unlikely (let us know if it
 396           happens to you).</para>
 397         </listitem>
 398       </varlistentry>
 399
 400       <varlistentry>
 401         <term>Use unboxed types (a GHC extension):</term>
 402         <listitem>
 403           <para>When you are <emphasis>really</emphasis> desperate for
 404           speed, and you want to get right down to the &ldquo;raw
 405           bits.&rdquo; Please see <xref linkend="glasgow-unboxed"/> for
 406           some information about using unboxed types.</para>
 407
 408           <para>Before resorting to explicit unboxed types, try using
 409           strict constructor fields and
 410           <option>-funbox-strict-fields</option> first (see above).
 411           That way, your code stays portable.</para>
 412         </listitem>
 413       </varlistentry>
 414
 415       <varlistentry>
 416         <term>Use <literal>foreign import</literal> (a GHC extension) to plug into fast libraries:</term>
 417         <listitem>
 418           <para>This may take real work, but&hellip; There exist piles
 419           of massively-tuned library code, and the best thing is not
 420           to compete with it, but link with it.</para>
 421
 422           <para><xref linkend="ffi"/> describes the foreign function
 423           interface.</para>
 424         </listitem>
 425       </varlistentry>
 426
 427       <varlistentry>
 428         <term>Don't use <literal>Float</literal>s:</term>
 429         <listitem>
 430           <para>If you're using <literal>Complex</literal>, definitely
 431           use <literal>Complex Double</literal> rather than
 432           <literal>Complex Float</literal> (the former is specialised
 433           heavily, but the latter isn't).</para>
 434
 435           <para><literal>Floats</literal> (probably 32-bits) are
 436           almost always a bad idea, anyway, unless you Really Know
 437           What You Are Doing.  Use <literal>Double</literal>s.
 438           There's rarely a speed disadvantage&mdash;modern machines
 439           will use the same floating-point unit for both.  With
 440           <literal>Double</literal>s, you are much less likely to hang
 441           yourself with numerical errors.</para>
 442
 443           <para>One time when <literal>Float</literal> might be a good
 444           idea is if you have a <emphasis>lot</emphasis> of them, say
 445           a giant array of <literal>Float</literal>s.  They take up
 446           half the space in the heap compared to
 447           <literal>Doubles</literal>.  However, this isn't true on a
 448           64-bit machine.</para>
 449         </listitem>
 450       </varlistentry>
 451
 452       <varlistentry>
 453         <term>Use unboxed arrays (<literal>UArray</literal>)</term>
 454         <listitem>
 455           <para>GHC supports arrays of unboxed elements, for several
 456           basic arithmetic element types including
 457           <literal>Int</literal> and <literal>Char</literal>: see the
 458           <literal>Data.Array.Unboxed</literal> library for details.
 459           These arrays are likely to be much faster than using
 460           standard Haskell 98 arrays from the
 461           <literal>Data.Array</literal> library.</para>
 462         </listitem>
 463       </varlistentry>
 464
 465       <varlistentry>
 466         <term>Use a bigger heap!</term>
 467         <listitem>
 468           <para>If your program's GC stats
 469           (<option>-S</option><indexterm><primary>-S RTS
 470           option</primary></indexterm> RTS option) indicate that it's
 471           doing lots of garbage-collection (say, more than 20&percnt;
 472           of execution time), more memory might help&mdash;with the
 473           <option>-M&lt;size&gt;</option><indexterm><primary>-M&lt;size&gt;
 474           RTS option</primary></indexterm> or
 475           <option>-A&lt;size&gt;</option><indexterm><primary>-A&lt;size&gt;
 476           RTS option</primary></indexterm> RTS options (see <xref
 477           linkend="rts-options-gc"/>).</para>
 478         </listitem>
 479       </varlistentry>
 480     </variablelist>
 481
 482 </sect1>
 483
 484 <sect1 id="smaller">
 485 <title>Smaller: producing a program that is smaller
 486 </title>
 487
 488 <para>
 489 <indexterm><primary>smaller programs, how to produce</primary></indexterm>
 490 </para>
 491
 492 <para>
 493 Decrease the &ldquo;go-for-it&rdquo; threshold for unfolding smallish
 494 expressions.  Give a
 495 <option>-funfolding-use-threshold0</option><indexterm><primary>-funfolding-use-threshold0
 496 option</primary></indexterm> option for the extreme case. (&ldquo;Only unfoldings with
 497 zero cost should proceed.&rdquo;)  Warning: except in certain specialised
 498 cases (like Happy parsers) this is likely to actually
 499 <emphasis>increase</emphasis> the size of your program, because unfolding
 500 generally enables extra simplifying optimisations to be performed.
 501 </para>
 502
 503 <para>
 504 Avoid <function>Read</function>.
 505 </para>
 506
 507 <para>
 508 Use <literal>strip</literal> on your executables.
 509 </para>
 510
 511 </sect1>
 512
 513 <sect1 id="thriftier">
 514 <title>Thriftier: producing a program that gobbles less heap space
 515 </title>
 516
 517 <para>
 518 <indexterm><primary>memory, using less heap</primary></indexterm>
 519 <indexterm><primary>space-leaks, avoiding</primary></indexterm>
 520 <indexterm><primary>heap space, using less</primary></indexterm>
 521 </para>
 522
 523 <para>
 524 &ldquo;I think I have a space leak&hellip;&rdquo; Re-run your program
 525 with <option>+RTS -S</option>, and remove all doubt!  (You'll
 526 see the heap usage get bigger and bigger&hellip;)
 527 &lsqb;Hmmm&hellip;this might be even easier with the
 528 <option>-G1</option> RTS option; so&hellip; <command>./a.out +RTS
 529 -S -G1</command>...]
 530 <indexterm><primary>-G RTS option</primary></indexterm>
 531 <indexterm><primary>-S RTS option</primary></indexterm>
 532 </para>
 533
 534 <para>
 535 Once again, the profiling facilities (<xref linkend="profiling"/>) are
 536 the basic tool for demystifying the space behaviour of your program.
 537 </para>
 538
 539 <para>
 540 Strict functions are good for space usage, as they are for time, as
 541 discussed in the previous section.  Strict functions get right down to
 542 business, rather than filling up the heap with closures (the system's
 543 notes to itself about how to evaluate something, should it eventually
 544 be required).
 545 </para>
 546
 547 </sect1>
 548
 549 </chapter>
 550
 551 <!-- Emacs stuff:
 552      ;;; Local Variables: ***
 553      ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
 554      ;;; End: ***
 555  -->