Skip to content

Commit 6736a4e

Browse files
committed
Add first-pass text
1 parent e99555e commit 6736a4e

File tree

4 files changed

+101
-9
lines changed

4 files changed

+101
-9
lines changed

Diff for: README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
# Website for python compilers workshop
22

33
Built using Jekyll + GH pages + the
4-
[Solo](https://chibicode.github.io/solo/) theme.
4+
[Solo](https://chibicode.github.io/solo/) theme (somewhat hacked).

Diff for: _config.yml

-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,5 @@
11
# Site settings
22
title: Python Compilers Workshop (July 11-12, 2016)
3-
tag_text: Python Compilers Workshop (July 11-12, 2016)
43
description: > # this means to ignore newlines until "baseurl:"
54
A workshop for folks working on Python compilers. July 11-12, 2016,
65
co-located with SciPy 2016 in Austin, Texas.

Diff for: _layouts/default.html

-1
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,6 @@
1111
</head>
1212
<body>
1313
<div class="container">
14-
<h1>{{ site.tag_text }}</h1>
1514
{{ content }}
1615
</div>
1716
{% include scripts.html %}

Diff for: index.md

+100-6
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,105 @@
22
layout: default
33
---
44

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
106

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).
1115

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

Comments
 (0)