mthl
/
texinfo


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
							<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:pls="http://www.w3.org/2005/01/pronunciation-lexicon" xmlns:ssml="http://www.w3.org/2001/10/synthesis" xmlns:svg="http://www.w3.org/2000/svg">
  <head>
    <title>Performance of numeric operations</title>
    <link rel="stylesheet" type="text/css" href="docbook-epub.css"/>
    <link rel="stylesheet" type="text/css" href="kawa.css"/>
    <script src="kawa-ebook.js" type="text/javascript"/>
    <meta name="generator" content="DocBook XSL-NS Stylesheets V1.79.1"/>
    <link rel="prev" href="Logical-Number-Operations.xhtml" title="Logical Number Operations"/>
    <link rel="next" href="Characters-and-text.xhtml" title="Characters and text"/>
  </head>
  <body>
    <header/>
    <section class="sect1" title="Performance of numeric operations" epub:type="subchapter" id="Performance-of-numeric-operations">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both">Performance of numeric operations</h2>
          </div>
        </div>
      </div>
      <p>Kawa can generally do a pretty good job of generating
efficient code for numeric operations, at least when
it knows or can figure out the types of the operands.
</p>
      <p>The basic operations <code class="literal">+</code>, <code class="literal">-</code>, and <code class="literal">*</code>
are compiled to single-instruction bytecode if both
operands are <code class="literal">int</code> or <code class="literal">long</code>.
Likewise, if both operands are floating-point (or
one is floating-point and the other is rational),
then single-instruction <code class="literal">double</code> or <code class="literal">float</code>
instructions are emitted.
</p>
      <p>A binary operation involving an infinite-precision <code class="literal">integer</code>
and a fixed-size <code class="literal">int</code> or <code class="literal">long</code> is normally
evaluated by expanding the latter to <code class="literal">integer</code>
and using <code class="literal">integer</code> arithmetic.  An exception is
an integer literal whose
value fits in an <code class="literal">int</code> or <code class="literal">long</code> - in that case
the operation is done using <code class="literal">int</code> or <code class="literal">long</code>
arithmetic.
</p>
      <p>In general, integer literals have amorphous type.
When used to infer the type of a variable, they have <code class="literal">integer</code> type:
</p>
      <pre class="screen">(let ((v1 0))
  ... v1 has type integer ... )
</pre>
      <p>However, a literal whose value fits in the <code class="literal">int</code> or <code class="literal">long</code> range
is implicitly viewed <code class="literal">int</code> or <code class="literal">long</code> in certain contexts,
primarily method overload resolution and binary arithmetic
(as mentioned above).
</p>
      <p>The comparison functions <code class="literal">&lt;</code>, <code class="literal">&lt;=</code>, <code class="literal">=</code>,
<code class="literal">&gt;</code>, and <code class="literal">=&gt;</code> are also optimized to single instriction
operations if the operands have appropriate type.
However, the functions <code class="literal">zero?</code>, <code class="literal">positive?</code>, and <code class="literal">negative?</code>
have not yet been optimized.
Instead of <code class="literal">(positive? x)</code> write <code class="literal">(&gt; x 0)</code>.
</p>
      <p>There are a number of integer division and modulo operations.
If the operands are <code class="literal">int</code> or <code class="literal">long</code>, it is faster
to use <code class="literal">quotient</code> and <code class="literal">remainder</code> rather
than <code class="literal">div</code> and <code class="literal">mod</code> (or <code class="literal">modulo</code>).
If you know the first operand is non-negative and the second is positive,
then use <code class="literal">quotient</code> and <code class="literal">remainder</code>.
(If an operand is an arbitrary-precision <code class="literal">integer</code>,
then it dosn’t really matter.)
</p>
      <p>The logical operations <code class="literal">bitwise-and</code>, <code class="literal">bitwise-ior</code>,
<code class="literal">bitwise-xor</code>, <code class="literal">bitwise-not</code>, <code class="literal">bitwise-arithmetic-shift-left</code>,
<code class="literal">bitwise-arithmetic-shift-right</code> are compiled
to single bitcode instructions if the operands are <code class="literal">int</code> or <code class="literal">long</code>.
Avoid <code class="literal">bitwise-arithmetic-shift</code> if the sign of the shift is known.
If the operands are arbitrary-precision <code class="literal">integer</code>,
a library call is needed, but run-time type dispatch is avoided.
</p>
    </section>
    <footer>
      <div class="navfooter">
        <p>
          Up: <a accesskey="u" href="Numbers.xhtml">Quantities and Numbers</a></p>
        <p>
        Previous: <a accesskey="p" href="Logical-Number-Operations.xhtml">Logical Number Operations</a></p>
      </div>
    </footer>
  </body>
</html>