Changes between Version 1 and Version 2 of PerformanceWarnings

Oct 2, 2010 5:40:24 PM (7 years ago)



  • PerformanceWarnings

    v1 v2  
    55The goal of this project is to have GHC guide the user to better performance, by warning of coding patterns that won't yield good performance.
     7== Approach ==
     9Users have trouble understanding how strictness analysis works, how demand analysis works, when and why things are specialized, inlined or unboxed. Our goal is for the compiler to tell them when such things happen, in order to guide them to better code.
     11== Stage 1: Performance Lint ==
     13=== Strictness Warnings ===
     15Users often feel a shotgun approach to strictness is the only way to fix performance or space problems. Due to difficulties reasoning about demand, a scattergun approach -- dropping bang patterns everywhere -- is used to squash laziness issues. This is usually unnecessary, and may make programs slower, than placing the getting the strictness precisely right.
     17'''The compiler should warn about unnecessary uses of bang patterns or seq.'''
     19=== Heuristics for "Probably a Performance Bug" ===
     21Atomic types:
     23 * Int, Word, Int*, Word*
     24 * Double, Float
     26should almost always be unboxed in users' code. It is exceedingly rare for such values to be necessarily lazy for correctness. However, due to insufficient strictness, such types are often inferred as lazy, and consequently not unboxed.
     28We can improve users' code by warning of any boxed types as arguments, or in data structures, for these types. Particularly accumulating parameters, or fields in record types. Additionally, if they are strict, but not unboxed, that should also be a warning.
     30=== Other heuristics ===
     32 * Warning any use of >>= that doesn't inline
     33 * Warn about lazy state monads
     34 * Warn about lazy tuples
     36== Output format ==
     38We could emit warnings about line / col number of values that "probably should be strict" or "have unnecessary bang patterns".
     40A more advanced option would be to reuse -fhpc to emit colorized source.
     42== Assertions ==
     44Once we can spot problems, the user could assert, via ANNOTATIONs, that particular properties must hold. These could trigger -Werrors.
     46== Results ==
     48Results for quality of the warnings can be measured:
     50 * Apply -fwarn-performance to a program
     51 * Do what it says
     52 * Measure the speedup.
     54== Implementation ==
     56Add a -fwarn-performance flag that does two things:
     58 * unnec. bang patterns/seq after strictness analysis
     59 * uses a library of heuristics (programmable?) to lint-check core.
     60 * The pass would be a core-to-warnings pass.