Gibt es Vorteile, die Python/C-Schnittstelle anstelle von Cython zu verwenden?

Lesezeit: 6 Minuten

Edouards Benutzeravatar
Eduard

Ich möchte Python und Numpy erweitern, indem ich einige Module in C oder C++ schreibe, mit BLAS und LAPACK. Ich möchte auch in der Lage sein, den Code als eigenständige C/C++-Bibliotheken zu verteilen. Ich möchte, dass diese Bibliotheken Float mit einfacher und doppelter Genauigkeit verwenden. Einige Beispiele für Funktionen, die ich schreiben werde, sind konjugierte Gradienten zum Lösen linearer Systeme oder beschleunigte Methoden erster Ordnung. Einige Funktionen müssen eine Python-Funktion aus dem C/C++-Code aufrufen.

Nachdem ich ein wenig mit der Python/C-API und der Numpy/C-API herumgespielt hatte, entdeckte ich, dass viele Leute stattdessen die Verwendung von Cython befürworten (siehe zum Beispiel diese oder diese Frage). Ich bin kein Experte für Cython, aber es scheint das für manche Fälle, müssen Sie immer noch die Numpy/C-API verwenden und wissen, wie sie funktioniert. Angesichts der Tatsache, dass ich bereits (etwas) Kenntnisse über die Python/C-API und keine über Cython habe, habe ich mich gefragt, ob es sinnvoll ist, die Python/C-API weiterhin zu verwenden, und ob die Verwendung dieser API einige Vorteile gegenüber Cython hat . In Zukunft werde ich sicherlich einige Sachen entwickeln, die keine numerische Berechnung beinhalten, also geht es bei dieser Frage nicht nur um numpy. Eine Sache, die ich an der Python/C-API mag, ist die Tatsache, dass ich einiges darüber lerne, wie der Python-Interpreter funktioniert.

Vielen Dank.

  • BLAS und LAPACK sind bereits in scipy integriert, wenn ich mich recht erinnere

    – fabrizioM

    19. April 2011 um 18:46 Uhr

  • Hinweis: Der von Ihnen bereitgestellte Link manche Fälle zeigt auf einen Code, der die Numpy/C-API von verwendet Cythonnicht C.

    – jfs

    19. April 2011 um 18:53 Uhr

  • @fabrizioM: Ja, BLAS und LAPACK werden in numpy und scipy verwendet. Aber ich möchte numerische Algorithmen entwickeln, die weder in numpy noch in scipy enthalten sind, und ich möchte dies aus Effizienzgründen in C/C++ tun.

    – Eduard

    19. April 2011 um 21:56 Uhr

  • @ JF Sebastian: Stimmt. Mein Punkt ist, dass dieser Code dem C-Code ziemlich nahe kommt, den man mit der Numpy/C-API schreiben würde: Das zugrunde liegende Verhalten muss bekannt sein (wie Referenzzählungen).

    – Eduard

    19. April 2011 um 22:09 Uhr

Die aktuelle “Top-Antwort” klingt in meinen Ohren etwas zu sehr nach FUD. Zum einen ist es nicht sofort offensichtlich, dass der durchschnittliche Entwickler schnelleren Code in C schreiben würde als das, was NumPy+Cython Ihnen sowieso gibt. Ganz im Gegenteil, die Zeit, die es braucht, um überhaupt den notwendigen C-Code in einer Python-Umgebung zum Laufen zu bringen, ist in der Regel viel besser investiert, um einen schnellen Prototypen in Cython zu schreiben, zu benchmarken, zu optimieren, schneller umzuschreiben, zu benchmarken wieder und dann zu entscheiden, ob irgendetwas darin wirklich die 5-10 % mehr Leistung erfordert, die Sie möglicherweise erhalten oder nicht, wenn Sie 2 % des Codes in handoptimiertem C neu schreiben und ihn aus Ihrem Cython-Code aufrufen.

Ich schreibe eine Bibliothek in Cython, die derzeit etwa 18.000 Zeilen Cython-Code enthält, was fast 200.000 Zeilen C-Code entspricht. Ich habe es einmal geschafft, ein paar sehr wichtige interne Basisfunktionen um fast 25 % zu beschleunigen, indem ich etwa 20 Zeilen handgetunten C-Codes an den richtigen Stellen eingefügt habe. Ich brauchte ein paar Stunden, um diesen winzigen Teil neu zu schreiben und zu optimieren. Das ist wirklich nichts im Vergleich zu der enormen Zeitersparnis, die ich dadurch gespart habe, dass ich die Bibliothek überhaupt nicht in einfachem C geschrieben (und gepflegt) habe.

Auch wenn Sie C viel besser kennen als Cython, wenn Sie Python kennen und C lernen Sie Cython so schnell, dass sich die Investition auf jeden Fall lohnt, besonders wenn Sie sich für Numerik interessieren. 80-95 % des Codes, den Sie schreiben, profitieren so sehr davon, dass er in einer Hochsprache geschrieben ist, dass Sie sich getrost zurücklehnen und die Hälfte der eingesparten Zeit in die Erstellung Ihres Codes genauso schnell investieren können, als ob Sie ihn geschrieben hätten sofort in einer einfachen Sprache.

Davon abgesehen ist Ihr Kommentar, dass Sie “den Code als eigenständige C/C++-Bibliotheken verteilen können möchten”, ein triftiger Grund, sich an einfaches C/C++ zu halten. Cython hängt immer von CPython ab, was eine ziemliche Abhängigkeit darstellt. Die Verwendung von einfachem C/C++ (mit Ausnahme der Python-Schnittstelle) ermöglicht es Ihnen jedoch auch nicht, NumPy zu nutzen, da dies auch von CPython abhängt. Wie üblich, wenn Sie etwas in C schreiben, müssen Sie also viel Grundlagenarbeit leisten, bevor Sie zur eigentlichen Funktionalität gelangen. Darüber sollten Sie sich ernsthaft Gedanken machen, bevor Sie mit dieser Arbeit beginnen.

Erstens, es gibt einen Punkt in Ihrer Frage, den ich nicht verstehe:

[…] möchten den Code auch als eigenständige C/C++-Bibliotheken verteilen können. […] Einige Funktionen müssen eine Python-Funktion aus dem C/C++-Code aufrufen.

Wie soll das funktionieren?

Als nächstes zu Ihrer eigentlichen Frage, es gibt sicherlich Vorteile, die Python/C-API direkt zu verwenden:

  • Höchstwahrscheinlich sind Sie mit dem Schreiben von C-Code besser vertraut als mit dem Schreiben von Cython-Code.

  • Das Schreiben Ihres Codes in C gibt Ihnen maximale Kontrolle. Um die gleiche Leistung von Cython-Code wie von entsprechendem C-Code zu erhalten, müssen Sie sehr vorsichtig sein. Sie müssen nicht nur sicherstellen, dass die Typen aller Variablen deklariert werden, Sie müssen auch einige Flags richtig setzen – nur ein Beispiel Grenzen prüfen. Sie müssen genau wissen, wie Cython arbeitet, um die beste Leistung zu erzielen.

  • Cython-Code hängt von Python ab. Es scheint keine gute Idee zu sein, Code zu schreiben, der auch als eigenständige C-Bibliothek in Cython verteilt werden sollte

  • “Wie soll das funktionieren?” — Die übliche Methode besteht darin, den Python-Interpreter einzubetten, oder?

    – Nikolaus Ritter

    20. April 2011 um 11:29 Uhr

  • @Nicholas: Ich weiß nicht, ob das OP das vorhat. Vielleicht sind die Funktionen, die Python-Funktionen aufrufen müssen, einfach nicht Teil der C-Bibliothek? Etwas Aufklärung wäre schön. (Und mir ist bewusst, dass dieser erste Teil eher ein Kommentar als eine Antwort ist, aber da ich sowieso eine Antwort geschrieben habe, habe ich ihn zur besseren Formatierung dort abgelegt.)

    – Sven Marnach

    20. April 2011 um 11:48 Uhr

  • Der Punkt, den Sie ansprechen, ist in der Tat nicht sehr klar. Was ich meinte, ist, dass einige Funktionen meiner Bibliothek benutzerdefinierte Funktionen als Argument verwenden. Python-Benutzer definieren diese Funktionen in Python und C/C++-Benutzer verwenden stattdessen Funktoren in C/C++. Ist das klarer?

    – Eduard

    20. April 2011 um 18:15 Uhr

  • Darüber hinaus scheint Cython Ihnen nicht die volle Sicherheit/Portabilität zu bieten, da sein Typsystem im Vergleich zu C ziemlich verarmt ist (obwohl size_t wurde schließlich in 0.11 hinzugefügt).

    – Fred Foo

    4. Mai 2011 um 7:57 Uhr

Der Hauptnachteil der Python/C-API besteht darin, dass sie sehr langsam sein kann, wenn sie in einer inneren Schleife verwendet wird. Ich sehe, dass das Aufrufen einer Python-Funktion einen 80-160-fachen Treffer gegenüber dem Aufrufen einer äquivalenten C++-Funktion erfordert.

Wenn das Ihren Code nicht stört, profitieren Sie davon, einige Codeabschnitte in Python schreiben zu können, Zugriff auf Python-Bibliotheken zu haben und direkt in Python geschriebene Callbacks zu unterstützen. Das bedeutet auch, dass Sie einige Änderungen ohne Neukompilierung vornehmen können, was das Prototyping vereinfacht.

  • In Python schreibt man keine engen Schleifen. Sie schreiben enge Schleifen in C und verbinden sie mit Python.

    – Alexander C.

    20. April 2011 um 11:41 Uhr

1408540cookie-checkGibt es Vorteile, die Python/C-Schnittstelle anstelle von Cython zu verwenden?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy