|
2 | 2 | layout: default
|
3 | 3 | ---
|
4 | 4 |
|
5 |
| -<!-- |
6 |
| - Note: Solo doesn't like use of top-level headlines. |
7 |
| - Headlines should use '##' or '###', etc., but never '#' |
8 |
| - ref: http://chibicode.github.io/solo |
9 |
| ---> |
| 5 | +# Python Compilers Workshop |
10 | 6 |
|
| 7 | +*What:* A workshop to bring together folks working on different |
| 8 | +approaches to **native-code compilation for Python**, to share |
| 9 | +experience, discuss future plans, and explore possible points of |
| 10 | +collaboration. One particular question to discuss is whether and how |
| 11 | +we can use JIT or AOT compilation techniques to accelerate C |
| 12 | +extensions like `numpy` or `pandas` without having to rewrite |
| 13 | +these extensions for every new compiler (as is the current |
| 14 | +state-of-the-art). |
11 | 15 |
|
12 |
| -Test test |
| 16 | +*When/where:* **July 11-12**, 2016 in **Austin, Texas**, co-located |
| 17 | +with the [SciPy 2016](scipy2016.scipy.org) conference. (This is just |
| 18 | +before the main conference, and overlaps with the SciPy tutorial |
| 19 | +days.) |
| 20 | + |
| 21 | +*Venue:* TBD |
| 22 | + |
| 23 | +*Who:* Open to the public. However |
| 24 | +[RSVP's are appreciated ](mailto:[email protected]) for planning purposes, |
| 25 | +and so that I can update the confirmed attendees list below. |
| 26 | + |
| 27 | +*Organized by: * Nathaniel Smith <[email protected]> |
| 28 | + |
| 29 | + |
| 30 | +## Motivation |
| 31 | + |
| 32 | +There's an intense and growing interest in techniques for compiling |
| 33 | +Python or near-Python languages; a partial list of projects includes |
| 34 | +[Numba](http://numba.pydata.org/), |
| 35 | +[Pyston](https://github.com/dropbox/pyston), [PyPy](http://pypy.org/), |
| 36 | +[Cython](http://cython.org/), |
| 37 | +[Pythran](https://github.com/serge-sans-paille/pythran), |
| 38 | +[Pyjion](https://github.com/Microsoft/Pyjion), |
| 39 | +[Nuitka](http://nuitka.net/), |
| 40 | +[Numexpr](https://github.com/pydata/numexpr), |
| 41 | +[HOPE](www.cosmology.ethz.ch/research/software-lab/HOPE.html), ... |
| 42 | + |
| 43 | +Given the wide variety of efforts here, now seems like a |
| 44 | +good time to compare notes! |
| 45 | + |
| 46 | +In addition, the numerical/scientific community is particularly |
| 47 | +interested in these tools as a way to speed up Python code that uses |
| 48 | +libraries like `numpy` -- and accomplishing this will require solving |
| 49 | +unique technical and organizational challenges. In principle it's not |
| 50 | +too difficult to compile Python code that uses `numpy` -- your |
| 51 | +compiler "just" has to be compatible enough with the CPython C API to |
| 52 | +call `numpy` directly, and all of the above projects either meet this |
| 53 | +bar, or are anticipated to meet it soon. (In particular, both Pyston |
| 54 | +and PyPy have developers actively working on this.) But if you want |
| 55 | +`numpy`-using code to run *faster* than it does with CPython -- which |
| 56 | +after all is the whole point of having a compiler -- then your |
| 57 | +compiler needs some way to "see inside" `numpy`'s internals in order |
| 58 | +to apply optimizations like unboxing, inlining, and loop fusion. And |
| 59 | +this is impossible when calling extensions using the CPython C API. |
| 60 | + |
| 61 | +Historically the main solution to this problem has been to start |
| 62 | +rewriting parts of `numpy` directly inside the compiler infrastructure |
| 63 | +-- projects that have gone down this road to a greater or lesser |
| 64 | +extent include Numba, PyPy, Cython, Numexpr, and probably others. And |
| 65 | +if nothing changes then this trend will only accelerate -- at an |
| 66 | +obvious cost in duplicate effort, compatibility, code maturity, and |
| 67 | +the ability to evolve and improve `numpy`'s semantics. Can we do |
| 68 | +better? Could there be some way to write a library like `numpy` so |
| 69 | +that a single codebase could simultaneously target CPython and the |
| 70 | +newer compilers, while achieving competitive speed in all cases? If |
| 71 | +so, can we make that happen? If not, then what's the next-best |
| 72 | +alternative? |
| 73 | + |
| 74 | + |
| 75 | +## Schedule |
| 76 | + |
| 77 | +TBD -- probably we'll start with a few short talks to set the stage |
| 78 | +and then switch to unconference mode. |
| 79 | + |
| 80 | + |
| 81 | +## Confirmed attendees |
| 82 | + |
| 83 | +TBD |
| 84 | + |
| 85 | + |
| 86 | +## Sponsors |
| 87 | + |
| 88 | +Sponsors: TBD |
| 89 | + |
| 90 | +We anticipate that we will have travel funding available for |
| 91 | +open-source developers who need the help. If this applies to you then |
| 92 | +[please get in touch ](mailto:[email protected]). |
| 93 | + |
| 94 | + |
| 95 | +## Travel information |
| 96 | + |
| 97 | +See the [SciPy 2016 web site](http://scipy2016.scipy.org/) for |
| 98 | +suggestions on |
| 99 | +[lodging](http://scipy2016.scipy.org/ehome/146062/332952/?&&), |
| 100 | +[transportation](http://scipy2016.scipy.org/ehome/146062/332955/?&&), |
| 101 | +and other travel details. |
| 102 | + |
| 103 | + |
| 104 | +## Code of conduct |
| 105 | + |
| 106 | +(TBD -- maybe we can just point to SciPy's?) |
0 commit comments