Changes between Version 2 and Version 3 of DeclareOptimize


Ignore:
Timestamp:
Jun 25, 2008, 8:30:48 PM (11 years ago)
Author:
pfeilgm
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeclareOptimize

    v2 v3  
    11== How Optimize Declarations are Implemented and What They Do ==
    2 
    3 {{{
    42
    53CCL uses a "policy object" to control how various speed/space/safety
     
    86exceptions) take a lexical environment as an argument.  There are
    97about a dozen such functions, and there are simple macros -
    10 POLICY.ALLOW-TAIL-RECURSION-ELIMINATION,  POLICY.OPEN-CODE-INLINE,
    11 etc - that can be used to access these functions.  There are separate
    12 policy objects used for interactive compilation and for COMPILE-FILE;
     8`POLICY.ALLOW-TAIL-RECURSION-ELIMINATION`, `POLICY.OPEN-CODE-INLINE`,
     9etc. - that can be used to access these functions.  There are separate
     10policy objects used for interactive compilation and for `COMPILE-FILE`;
    1311all are equivalent by default,  but the idea is that people might  want
    1412to be more aggressive when compiling a file than when defining things
    1513interactively, or might not.
    1614
    17 -Most- speed/safety/space/debugging tradeoffs are made by calling
     15_Most_ speed/safety/space/debugging tradeoffs are made by calling
    1816a function in the current/active policy object with the lexical
    1917environment as an argument; the function typically returns a boolean
    20 result based on the values of the OPTIMIZE quantities in that
     18result based on the values of the `OPTIMIZE` quantities in that
    2119environment.  For instance, a tail-call is optimized (the caller's
    22 stack frame is reused) if the POLICY.ALLOW-TAIL-RECURSION-ELIMINATION
     20stack frame is reused) if the `POLICY.ALLOW-TAIL-RECURSION-ELIMINATION`
    2321function in the current policy returns true.  The value of this function
    2422could be something like:
    2523
    26 
    27   #'(lambda (env)
    28      (< (debug-optimize-quantity env) 2))
     24{{{
     25#'(lambda (env)
     26    (< (debug-optimize-quantity env) 2))
     27}}}
    2928
    3029so tail-call optimization will happen (under a policy with this
    31 function) when DEBUG is less than 2.
     30function) when `DEBUG` is less than 2.
    3231
    3332
     
    3534include
    3635
    37  - POLICY.OPEN-CODE-INLINE controls whether certain  fairly
     36 * `POLICY.OPEN-CODE-INLINE` controls whether certain  fairly
    3837   long instruction sequences are done inline or not.  One case
    3938   of this involves special variable reference:  it takes around 8
     
    4241   real value or unbound), and a call/return to a runtime routine
    4342   (a "subprimitive") adds a few cycles of insult to injury.  If the
    44    lisp kernel profile shows a lot of time spent in _SPspecrefcheck,
     43   lisp kernel profile shows a lot of time spent in `_SPspecrefcheck`,
    4544   it might help to spend less time doing special variable references
    4645   inline.  The default policy function says that things should
     
    5150   if this happens that often you're probably losing anyway.)
    5251
    53  - POLICY.INHIBIT-SAFETY-CHECKING can make correct code faster and
     52 * `POLICY.INHIBIT-SAFETY-CHECKING` can make correct code faster and
    5453   incorrect code crash.  When this is true (by default, only when
    55    SPEED is 3 and SAFETY is 0), functions that take a fixed number
     54   `SPEED` is 3 and `SAFETY` is 0), functions that take a fixed number
    5655   of arguments assume that they got the correct number of arguments
    5756   and can crash spectacularly if that's not true; if your program is
     
    6362   some hint/clue as to the array's type.
    6463
    65  - POLICY.TRUST-DECLARATIONS controls whether type-declarations
    66    are used; it is true by default when SAFETY is less than 3 and SPEED
    67    is greater or equal to SAFETY.  If the compiler trusts type
     64 * `POLICY.TRUST-DECLARATIONS` controls whether type-declarations
     65   are used; it is true by default when `SAFETY` is less than 3 and `SPEED`
     66   is greater or equal to `SAFETY`.  If the compiler trusts type
    6867   declarations, then different things can happen depending on the
    6968   type in question:
    70 
    71    -- for some types, the declaration is "blindly" trusted: if
    72    X and Y are declared to be FIXNUMs and declarations are trusted,
     69   * for some types, the declaration is "blindly" trusted: if
     70   X and Y are declared to be `FIXNUM`s and declarations are trusted,
    7371   then arithmetic operations involving X and Y will try to do
    7472   fixnum arithmetic without typechecking.  (Part of the rationale
    7573   is that the typechecking in that case is likely to be more
    7674   expensive than the arithmetic); unsafe code can also be
    77    generated for operations like CAR and CDR on values declared
    78    to be LISTs.
    79 
    80    -- for other types and primitive operations on them, trusted
     75   generated for operations like `CAR` and `CDR` on values declared
     76   to be `LIST`s.
     77   * for other types and primitive operations on them, trusted
    8178   declarations might influence the compiler to generate type-specific
    8279   code, but code is still safe ("trust, but verify") unless
    83    POLICY.INHIBIT-SAFETY-CHECKING suggests otherwise.
     80   `POLICY.INHIBIT-SAFETY-CHECKING` suggests otherwise.
    8481
    85 With the exception of cases involving FIXNUM and LIST declarations,
     82With the exception of cases involving `FIXNUM` and `LIST` declarations,
    8683code compiled at default optimization settings is generally as
    8784safe as code compiled at high safety; in practice, people don't
    88 seem to often declare things to be FIXNUMs or LISTs unless they're
    89 pretty sure that that's the case.  (Some of the FIXNUM/LIST stuff
     85seem to often declare things to be `FIXNUM`s or `LIST`s unless they're
     86pretty sure that that's the case.  (Some of the `FIXNUM`/`LIST` stuff
    9087is historical: it was probably once several times more expensive
    9188to be safe than unsafe; now it is probably only 2 or 3 times as
    9289expensive.)
    9390
    94 SAFETY 3 is generally implemented by forcing the compiler to be
     91`SAFETY` 3 is generally implemented by forcing the compiler to be
    9592stupidly conservative about practically everything: compiler macros
    9693aren't expanded, function calls are (almost always) compiled as
     
    9895could be performed safely.)  I'd like to try to get away from
    9996this implementation strategy, but it's currently the case that
    100 SAFETY 3 sacrifices (in some cases) a lot of performance for
     97`SAFETY` 3 sacrifices (in some cases) a lot of performance for
    10198what's in practice only occasionally more safety than is available
    10299under default settings.
     
    105102that can be hard to debug, partly because stack discipline may
    106103be violated.  When the callee is constant and the arguments
    107 are explicit, mismatches can be warned about; if FUNCALL and
    108 APPLY are used relatively rarely, then the risk of an undetected
     104are explicit, mismatches can be warned about; if `FUNCALL` and
     105`APPLY` are used relatively rarely, then the risk of an undetected
    109106number-of-args error is (in some sense) small.
    110 
    111 }}}