Serge Guelton (serge-sans-paille)

7 years ago, a first file was commited in the Pythran git repo in order to create a compiler from Python to C++. The project now has hundreds of downloads per day on PyPI and has moved to a cross-platform compiler for scientific programs. This talks walks through the initial ideas, sorting out the good and the bad ones and compares the approach with other major Python compilers for scientific programs, most notably Cython, Pypy and Numba.

Relevant topics include :

• Numpy compatibility
• Abstraction level
• Backward compatibility with Python
• Taking advantage of hardware
• Translating or optimizing
• Community interaction
• Multi-platform support
• Benchmarking

GCC is the default toolchain to build C/C++ packages in Fedora. Meanwhile OpenMandrivia already builds most of its package with the LLVM toolchain, the Debian archive is regularly rebuilt with with a recent verion of clang... So could we try that for Fedora?

This talk describes an on-going effort to achieve that goal while keeping the same compiler feature set as GCC.

Subtopics of the talk include:

• Creating a clang-based buildroot and use it to rebuild the fedora user-land (and more?)
• Support for missing security features such as -fstack-clash-protection or -DFORTIFYSOURCE=2
• Add missing features for the annobin tool within lld
• Python3 compatibity
• Package size

Where is the documentation of the LLVM Pass InstCombine? Is it accurate? Is there any default example? Is it tested?

Compiler guys love generated code. So in our obfuscating compiler, we have a declarative format to specify tons of stuff on our passes: its name, it's application level, its documentation, a sample usage, its options (with default values, help string etc), but also it's priority in the pass pipeline and a few other stuff specific to a code obfuscator. And everything is consistent, from sphinx-generated documentation to inline help and even tests! Let's have a look at this, and maybe influence the way it's done in LLVM.

Pythran is an open source compiler for scientific kernels written in Python.

Its goal is to turn scientific kernels written in Python into native modules that runs much faster, take advantage of SIMD instruction units, multi-cores, get rid of the GIL without sacrifying high-level programing. As such it understands a strict subset of the Python language, keeping 100% backward compatibiliy with the original language.

Looks cool? It is. But the target niche is small (high performance computing in Python and several great tools already exist (Cython, Numba). How have Pythran survived in the OSS jungle for 6 years while gathering a small but living community?

The following points will be discussed:

• making reasonable technical choices
• targeting a niche
• sharing the joy
• surviving the Python3 switch
• building a community
• surviving the bus factor
• finding funding
• not becoming a workaholic