Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.lispworks.com/documentation/lw71/LW/html/lw-64.htm below:

9.5 Compiler control

There are ways to control the nature of compiled code via the declare special form and proclaim function. See Declare, proclaim, and declaim for fuller discussion of these two forms.

In particular there are a set of optimize qualities which take integral values from 0 to 3. These control the trade-offs between size, speed, retention of debug information, optimizations and safety (that is, type checks) in the resulting code, and also compilation time. For example:

tells the compiler to concentrate on code speed rather than anything else, and

ensures that the compiler never takes liberties with Lisp semantics and produces code that checks for every kind of error that can be signaled.

The important declarations to the compiler are type declarations and optimize declarations. To declare that the type of the value of a variable can be relied upon to be unchanging (and hence allow the compiler to omit various checks in the code), say:

Optimize declarations have various qualities, and these take values from 0 to 3. The names are safety, fixnum-safety, float, sys:interruptable, debug, speed, compilation-speed, and space.

Most of the qualities default to 1 (but safety and fixnum-safety default to 3 and interruptable defaults to 0). You can either associate an optimize quality with a new value (with local lexical scope if in declare, and global scope if proclaim), or just give it by itself, which implies the value 3 (taken to mean "maximum" in some loose sense).

Thus you ensure code is at maximum safety by:

or

and reduce debugging information to a minimum by

Normally code is interruptible, but when aiming for maximum speed and minimum safety and debug information code is not interruptible unless you ensure it thus:

The levels of safety have the following implications:

• 0 implies no type checking upon reading or writing from defstructs, arrays and objects in general, nor any checking of array index bounds.
• 1 implies no type checking upon reading from defstructs, arrays and objects in general, nor any checking of array index bounds when reading. However, array index bounds are checked when writing.
• 2 implies type checking when writing, but not when reading. Other than this the compiler generates generally safe code, but allows type and fixnum-safety declarations to take effect. Array index bounds are checked for both reading and writing.
• 3 (default) implies complete type and bounds checking, and disallows fixnum-safety and type declarations from taking any effect.

The levels of fixnum-safety have the following implications:

• 0 implies no type checking of arguments to numeric operations, which are assumed to be fixnums. Also the result is assumed, without checking, to not overflow - this level means single machine instructions can be generated for most common integer operations, but risks generating values that may confuse the garbage collector.
• 1 implies that numeric operations do not check their argument types (assumed fixnum), but do signal an error if the result would have been out of range.
• 2 implies that numeric operations signal an error if their arguments are non-fixnum, and also check for overflow.
• 3 (default) implies complete conformance to the semantics of Common Lisp numbers, so that types other than integers are handled in compiled code.

Additionally if the level of float (really this should be called "float-safety") is 0 then the compiler reduces allocation during float calculations.

The effects of combining these qualities is summarized below:

Keyword settings

Operations

safety=0

Array access optimizations

debug>0

Dumps symbol names for arglist

debug>=2

Ensure debugger knows values of args (and variables when source level debugging is on) and can find the exact subform in the Editor.

debug<1

Does not generate any debug info at all

debug=3

Avoids make-instance and
find-class optimizations

debug=3

Avoids gethash and puthash optimizations

debug=3

Avoids ldb and dpb optimizations

debug=3

Avoids an optimization to last

safety>1

Be careful when multiple value counts are wrong

safety<1

Do not check array indices during write

safety<2

Do not check array indices during read

speed>space

Inline map functions (unless debug>2)

debug<=2

Optimize (merge) tail calls

debug<2 and safety<2

Self calls

safety>=2

Check get special

safety<2

Do not check types during write

safety<3

Do not check types during read

safety>=1

Check structure access

safety<=1

Inline structure readers, with no type check

safety=0

Inline structure writers, with no type check

safety>1

Check number of args

safety>=1 or
interruptible>0

Check stack overflow

safety>1

Ensures the thing being funcalled is a function

safety<3 and
fixnum-safety=2

Fixnum-only arithmetic with errors for
non fixnum arguments.

safety<3 and
fixnum-safety=1

No fixnum overflow checks

safety<3 and
fixnum-safety=0

No fixnum arithmetic checks at all

safety>2

char= checks for arguments of type character

safety>=2

Ensures symbols in progv

debug=3

Avoids "ad hoc" predicate type transforms

compilation-speed=3

Reuse virtual registers in very large functions

debug=3 and safety=3

(declare (type foo x)) and
(the foo x) ensure a type check

float=0

Optimize floating point calculations

The other optimize qualities are: speed -- the attention to fast code, space -- the degree of compactness, compilation-speed -- speed of compilation, interruptable -- whether code must be interruptible when unsafe.

Note that if you compile code with a low level of safety, you may get segmentation violations if the code is incorrect (for example, if type checking is turned off and you supply incorrect types). You can check this by interpreting the code rather than compiling it.

The following function, compiled with safety = 2, does not check the type of its argument because it merely reads:

(defun foo (x)

  (declare (optimize (safety 2)))

  (car x))

However the following function, also compiled with safety = 2, does check the type of its argument because it writes:

(defun set-foo (x y)

  (declare (optimize (safety 2)))

  (setf (car x) y))

As another example, interpreted code and code compiled at at low safety does not check type declarations. To make LispWorks check declarations, you need to compile your code after doing:

This last example shows how to copy efficiently bytes from a typed-aref vector (see make-typed-aref-vector) to an (unsigned-byte 8) array. type and safety declarations cause the compiler to inline the code that deals specifically with (unsigned-byte 8). This code was developed after an application was found to have a bottleneck in the original version of this function:

(defun copy-typed-aref-vector-to-byte-vector

       (byte-vector typed-vector length)

  (declare (optimize (safety 0))

           (type (simple-array (unsigned-byte 8) 1) byte-vector)

           (fixnum length))

  (dotimes (index length)

    (declare (type fixnum index))

    (setf (aref byte-vector index)

          (sys:typed-aref '(unsigned-byte 8) 

                          typed-vector index))))

LispWorks User Guide and Reference Manual - 20 Sep 2017

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4