Skip to content

Files

Latest commit

bf3253d · Feb 9, 2017

History

History
This branch is 12008 commits ahead of, 23287 commits behind halide/Halide:main.

python_bindings

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Dec 15, 2016
Aug 10, 2016
Sep 6, 2016
Feb 9, 2017
May 9, 2016
Dec 15, 2016
May 12, 2016
Mar 9, 2016
Aug 3, 2015
Aug 26, 2016
Aug 3, 2015
Aug 3, 2015
Aug 7, 2015
Aug 7, 2015

Prerequisites

The bindings (and demonstration applications) should work well both for python2.7 and python3.4 (or higher), and across platforms.

(Currently only tested on Ubuntu 14.04 and OS X 10.10 with python3.4 and a Halide source build).

Python requirements:

See requirements.txt (to be used with pip: pip install --user requirements.txt)

C++ requirements:

Halide compiled (assuming halide_git_clone_path/build). For a better python experience make sure Halide was compiled with WITH_EXCEPTIONS Boost.python (already available in most boost distributions) Recommended (used for I/O): Boost.Numpy https://github.com/ndarray/Boost.NumPy

Compilation instructions

Build using:

  mkdir build
  cd build
  ccmake ..
  make 

Documentation and Examples

The Python API reflects directly the C++ Halide API. Consult the module documentation.

Check out the code for the example applications in the apps/ and tutorial/ subdirectory.

You can run them as a batch via:

    run_apps.sh
    run_tutorial.sh

To run these examples, make sure the PYTHONPATH environment variable points to your build directory (e.g. export PYTHONPATH=halide_source/python_bindings/build:$PYTHONPATH).

License

The Python bindings use the same MIT license as Halide.

Python bindings provided by Connelly Barnes (2012-2013), Fred Rotbart (2014), Rodrigo Benenson (2015) and the Halide open-source community.

Why did we move from SWIG to Boost.Python ?

Problems with (old) SWIG bindings:

  • P1) SWIG cannot parse C++15, and it will always lag
  • P2) Python code is not compiled/tested together with C++ codebase
  • P3) Albeit SWIG is ment to provide "automagic" conversion, current code base has explicit code for every class (and class member) of interest
  • P4) Old swig bindings __init__.py file has a lot of "python magic" to get things running, code is spread around multiple pieces (py_util.cpp, cHalide.i, and __init__.py)
  • P5) Old swig python bindings did not work anymore (swig issues, compilation issues)

The boost python approach helps because:

  • a) P1 is solved out of the box, since no C++ parsing is involved
  • b) P2 is mitigated since python bindings are also in C++. Any miss-match with generate a compilation error.
  • c) P3, P4 and P5 are expected to be handled by having less spaghetti and aiming for tighter integration with rest of code-base (point b)