Python Semantik

Python ist schwer zu optimieren, da fast alles veränderlich ist: eingebaute Funktionen, Funktionscodes, globale Variablen, lokale Variablen, ... können zur Laufzeit geändert werden. Die Implementierung von Optimierungen, die die Python-Semantik respektieren, erfordert die Erkennung, wenn „etwas sich ändert“. Wir werden diese Prüfungen als „Guards“ bezeichnen.

Diese PEP schlägt vor, eine öffentliche API zur Python C API hinzuzufügen, um spezialisierte Codes mit Guards zu einer Funktion hinzuzufügen. Wenn die Funktion aufgerufen wird, wird ein spezialisierter Code verwendet, wenn nichts geändert wurde, andernfalls wird der ursprüngliche Bytecode verwendet.

Auch wenn Guards helfen, die meisten Teile der Python-Semantik zu respektieren, ist es schwer, Python zu optimieren, ohne subtile Änderungen am exakten Verhalten vorzunehmen. CPython hat eine lange Geschichte und viele Anwendungen verlassen sich auf Implementierungsdetails. Es muss ein Kompromiss zwischen „alles ist veränderlich“ und Leistung gefunden werden.

Das Schreiben eines Optimierers liegt außerhalb des Umfangs dieser PEP.

Warum kein JIT-Compiler?

Es gibt mehrere JIT-Compiler für Python, die aktiv entwickelt werden

• PyPy
• Pyston
• Numba
• Pyjion

Numba ist speziell für numerische Berechnungen. Pyston und Pyjion sind noch jung. PyPy ist der vollständigste Python-Interpreter, er ist im Allgemeinen schneller als CPython in Mikro- und vielen Makro-Benchmarks und hat eine sehr gute Kompatibilität mit CPython (er respektiert die Python-Semantik). Es gibt immer noch Probleme mit Python JIT-Compilern, die ihre breite Verwendung anstelle von CPython verhindern.

Viele beliebte Bibliotheken wie numpy, PyGTK, PyQt, PySide und wxPython sind in C oder C++ implementiert und verwenden die Python C API. Um einen geringen Speicherbedarf und bessere Leistung zu erzielen, verwenden Python JIT-Compiler keine Referenzzählung, um einen schnelleren Garbage Collector zu verwenden, sie verwenden keine C-Strukturen von CPython-Objekten und verwalten Speicherzuweisungen anders. PyPy verfügt über ein cpyext-Modul, das die Python C API emuliert, aber es hat schlechtere Leistungen als CPython und unterstützt nicht die vollständige Python C API.

Neue Funktionen werden zuerst in CPython entwickelt. Im Januar 2016 ist die neueste stabile CPython-Version 3.5, während PyPy nur Python 2.7 und 3.2 unterstützt und Pyston nur Python 2.7 unterstützt.

Auch wenn PyPy eine sehr gute Kompatibilität mit Python hat, sind einige Module immer noch nicht mit PyPy kompatibel: siehe PyPy Compatibility Wiki. Die unvollständige Unterstützung der Python C API ist Teil dieses Problems. Es gibt auch subtile Unterschiede zwischen PyPy und CPython wie die Referenzzählung: Objekt-Destruktoren werden in PyPy immer aufgerufen, können aber „später“ aufgerufen werden als in CPython. Die Verwendung von Kontextmanagern hilft, zu kontrollieren, wann Ressourcen freigegeben werden.

Auch wenn PyPy in einer Vielzahl von Benchmarks viel schneller als CPython ist, berichten einige Benutzer immer noch über schlechtere Leistungen als CPython in einigen spezifischen Anwendungsfällen oder instabile Leistungen.

Wenn Python als Skriptprogramm für Programme verwendet wird, die weniger als 1 Minute laufen, können JIT-Compiler langsamer sein, da ihre Startzeit höher ist und der JIT-Compiler Zeit für die Optimierung des Codes benötigt. Zum Beispiel dauern die meisten Mercurial-Befehle nur wenige Sekunden.

Numba unterstützt jetzt Ahead-of-Time-Kompilierung, erfordert aber Dekoratoren zur Angabe von Argumenttypen und unterstützt nur numerische Typen.

CPython 3.5 hat fast keine Optimierung: Der Peephole-Optimizer implementiert nur grundlegende Optimierungen. Ein statischer Compiler ist ein Kompromiss zwischen CPython 3.5 und PyPy.

Hypothetisches myoptimizer Modul

Beispiele in dieser PEP verwenden ein hypothetisches myoptimizer-Modul, das die folgenden Funktionen und Typen bereitstellt

• specialize(func, code, guards): Fügt den spezialisierten Code code mit Guards guards zur Funktion func hinzu
• get_specialized(func): Ruft die Liste der spezialisierten Codes als Liste von (code, guards)-Tupeln ab, wobei code ein Callable oder ein Code-Objekt ist und guards eine Liste von Guards ist
• GuardBuiltins(name): Guard, der builtins.__dict__[name] und globals()[name] überwacht. Der Guard schlägt fehl, wenn builtins.__dict__[name] ersetzt wird oder wenn globals()[name] zugewiesen wird.

Verwendung von Bytecode

Fügt spezialisierten Bytecode hinzu, bei dem der Aufruf der reinen eingebauten Funktion chr(65) durch ihr Ergebnis "A" ersetzt wird

import myoptimizer

def func():
    return chr(65)

def fast_func():
    return "A"

myoptimizer.specialize(func, fast_func.__code__,
                       [myoptimizer.GuardBuiltins("chr")])
del fast_func

Beispiel, das das Verhalten des Guards zeigt

print("func(): %s" % func())
print("#specialized: %s" % len(myoptimizer.get_specialized(func)))
print()

import builtins
builtins.chr = lambda obj: "mock"

print("func(): %s" % func())
print("#specialized: %s" % len(myoptimizer.get_specialized(func)))

Ausgabe

func(): A
#specialized: 1

func(): mock
#specialized: 0

Der erste Aufruf verwendet den spezialisierten Bytecode, der den String "A" zurückgibt. Der zweite Aufruf entfernt den spezialisierten Code, da die eingebaute Funktion chr() ersetzt wurde, und führt den ursprünglichen Bytecode aus, der chr(65) aufruft.

In einem Mikrobenchmark dauert der Aufruf des spezialisierten Bytecodes 88 ns, während die ursprüngliche Funktion 145 ns (+57 ns) benötigt: 1,6-mal schneller.

Verwendung einer eingebauten Funktion

Fügt die C-eingebaute Funktion chr() als spezialisierten Code hinzu, anstatt eines Bytecodes, der chr(obj) aufruft

import myoptimizer

def func(arg):
    return chr(arg)

myoptimizer.specialize(func, chr,
                       [myoptimizer.GuardBuiltins("chr")])

Beispiel, das das Verhalten des Guards zeigt

print("func(65): %s" % func(65))
print("#specialized: %s" % len(myoptimizer.get_specialized(func)))
print()

import builtins
builtins.chr = lambda obj: "mock"

print("func(65): %s" % func(65))
print("#specialized: %s" % len(myoptimizer.get_specialized(func)))

Ausgabe

func(): A
#specialized: 1

func(): mock
#specialized: 0

Der erste Aufruf ruft die C-eingebaute Funktion chr() auf (ohne einen Python-Frame zu erstellen). Der zweite Aufruf entfernt den spezialisierten Code, da die eingebaute Funktion chr() ersetzt wurde, und führt den ursprünglichen Bytecode aus.

In einem Mikrobenchmark dauert der Aufruf des C-eingebauten Funktions 95 ns, während der ursprüngliche Bytecode 155 ns (+60 ns) benötigt: 1,6-mal schneller. Der direkte Aufruf von chr(65) dauert 76 ns.

Funktions-Guard

Fügt ein Funktions-Guard-Objekt hinzu

typedef struct {
    PyObject ob_base;
    int (*init) (PyObject *guard, PyObject *func);
    int (*check) (PyObject *guard, PyObject **stack, int na, int nk);
} PyFuncGuardObject;

Die Funktion init() initialisiert einen Guard

• Gibt 0 bei Erfolg zurück
• Gibt 1 zurück, wenn der Guard immer fehlschlägt: PyFunction_Specialize() muss den spezialisierten Code ignorieren
• Löst eine Ausnahme aus und gibt -1 bei einem Fehler zurück

Die Funktion check() prüft einen Guard

• Gibt 0 bei Erfolg zurück
• Gibt 1 zurück, wenn der Guard vorübergehend fehlgeschlagen ist
• Gibt 2 zurück, wenn der Guard immer fehlschlägt: Der spezialisierte Code muss entfernt werden
• Löst eine Ausnahme aus und gibt -1 bei einem Fehler zurück

stack ist ein Array von Argumenten: indizierte Argumente gefolgt von (key, value)-Paaren von Keyword-Argumenten. na ist die Anzahl der indizierten Argumente. nk ist die Anzahl der Keyword-Argumente: die Anzahl der (key, value)-Paare. stack enthält na + nk * 2 Objekte.

Spezialisierter Code

Fügt eine spezialisierte Code-Struktur hinzu

typedef struct {
    PyObject *code;        /* callable or code object */
    Py_ssize_t nb_guard;
    PyObject **guards;     /* PyFuncGuardObject objects */
} PySpecializedCode;

Funktionsmethoden

int PyFunction_Specialize(PyObject *func,
                          PyObject *code, PyObject *guards)

PyObject* PyFunction_GetSpecializedCodes(PyObject *func)

PyObject* PyFunction_GetSpecializedCode(PyObject *func,
                                        PyObject **stack,
                                        int na, int nk)

int PyFunction_RemoveSpecialized(PyObject *func, Py_ssize_t index)

int PyFunction_RemoveAllSpecialized(PyObject *func)

Benchmark

Mikrobenchmark auf python3.6 -m timeit -s 'def f(): pass' 'f()' (Best of 3 Runs)

• Original Python: 79 ns
• Gepatchtes Python: 79 ns

Laut diesem Mikrobenchmark haben die Änderungen keinen Overhead beim Aufruf einer Python-Funktion ohne Spezialisierung.