# Compiling Your Program

:::{note}
We've come to the end of the programming tips to make your code
run faster. The rest of this page offers methods of compiling your
code in ways that can increase its speed. Note that I have not personally explored
the Python-based options.
:::

## Python

If you want the friendliness of the Python language syntax, but the
speed of a compiled language, there are compilers for Python.

These are installed on the Nevis particle-physics Linux cluster. If
you visit the links below, you can ignore the installation
instructions if you're using one of the computers on the cluster, or
you're using {ref}`the notebook server`.

### Numba

[Numba](https://numba.readthedocs.io/en/stable/index.html) is a
"just-in-time" compiler for Python. Basically, you create some code
within a Python
[decorator](https://www.programiz.com/python-programming/decorator)
that Numba will compile the first time the decorated function is
called. After the compilation, the function will execute at C-level
speed.

### Cython

[Cython](https://cython.readthedocs.io/en/stable/src/tutorial/index.html)
is both a compiler and a language extension for Python. 

In general, you'll want to use Cython from the command line, as you
would C++. But you can use it on our notebook server. The [Nevis wiki
Jupyter page](https://twiki.nevis.columbia.edu/twiki/bin/view/Main/IPython) has an
[example](https://twiki.nevis.columbia.edu/twiki/bin/view/Main/IPython#Cython).

## C++

On the Nevis particle-physics [Linux
cluster](https://twiki.nevis.columbia.edu/twiki/bin/view/Main/LinuxCluster),
the [GNU C++
compiler](https://twiki.nevis.columbia.edu/twiki/bin/view/Main/LinuxCluster)
is standard. Its major competitor is
[clang](https://clang.llvm.org/).

By default, both compilers produce code that is optimized for
debugging. But once you're convinced that your code works, you may
want to get some extra speed by setting the `-O3` option, which
optimizes the code for execution speed.[^debug]$^{,}$[^oops]

For example:

    g++ `root-config --cflags --libs` analysis.cc -o analysis -O3

:::{figure-md} academia_vs_business-fig
:align: center

<img src="https://imgs.xkcd.com/comics/academia_vs_business.png" alt="xkcd academia_vs_business" width="100%">

<https://xkcd.com/664/> by Randall Munroe
:::

[^debug]: Why should optimizing the code for speed make it harder to
    debug? Take another look at {numref}`Listing %s <bad-c-code>`, the
    example of "bad" C++ code. I {ref}`described <faster
    code>` how the code calculated values that were computed
    more than once, even though their values were unchanged in the
    loop. An optimizing compiler would pull out any code that was
    independent of the loop, and execute it before the loop started.

    However, it would do this on the machine-language level (or on the
    [LLVM](https://llvm.org/) level, a topic way beyond the scope of
    both this tutorial and this footnote). There would no longer be a
    correpondence between a bit of code that the computer executed and
    a given line in your program. This means that any error messages
    generated during the execution of your program would be harder to
    track down.

[^oops]: Did I just give away an answer to a question I posed back in
    {ref}`Exercise 11 <stand-alone-c>`? Oops!