Modellierung von Schaukeln

[1] Laut dem Podcast wurde das Schaukeln (swing up task) als Differentialgleichung 2. Ordnung modelliert. Damit sind linerare Gleichungen gemeint, die 2 Inputvariablen besitzen. Differentialgleichungen sind ein Konzept was früher auf Analogcomputern verwendet wurde. Besser sind turing-mächtige Modelle (Finite State Machine). Soetwas benötigt man beispielsweise wenn man einen Zeichentrickfilm a la Pixar modellieren möchte. Dennoch war der Podcast ein guter Einstieg ins Thema und es es ist schön dass das Thema auf Deutsch aufgegriffen wurde. Warum das Karlsruher Institut für Mathematik noch mit Analog-computern arbeitet und nicht schon etwas moderner aufgestellt ist schade.

[2] Der obige Podcast mit dem Thema Schaukeln war noch einer von den besseren Folgen. Hört man in die Episode #111 des „Modelansatz“ Podcast hinein wo es um Mathematik ganz allgemein geht, sträuben sich die Nackenhaare auf über soviel Unverständnis der Mathematik gegenüber. Man kann es nicht anders sagen, aber die Episode hat fast nichts mit Mathematik zu tun, stattdessen werden dort gesellschaftliche Dinge besprochen wie Stuttgart 21, die Vermittlung von Mathematik in der Schule sowie die Situation an den Unis (Stichwort Halbtagsstelle). Mag sein, dass auch diese Folge am renomierten Karlsruher Institut für Mathematik entstanden ist, aber mit Wissenschaft hat das fast nichts mehr zu tun. Es ist vielmehr ein Beispiel dafür, was alles falsch läuft in der Wissenschaft.

Das Hauptproblem scheint mir zu sein, dass sich die Vortragenden in der Verantwortung als Wissenschaftler sehen anstatt sich als Programmierer / Hacker oder Anti-Scientists zu verstehen. Einmal mehr zeigt sich, dass die Strikte Trennung zwischen theoretischer Informatik und Mathematik keine gute Entscheidung war.

Roboter — warum?

Sebastian Thrun hat einmal seine Motivation erläutert sich mit autonomen Autos zu beschäftigen. Und zwar möchte er gerne die Verkehrsunfälle auf Null reduzieren und damit sehr viele Menschenleben retten. Und in der Tat, wenn es gelänge autonomes Fahren voranzutreiben stehen die Chancen gut dass die mehr als 1 Millionen verkehrstote im Jahr reduziert werden.

Es gibt aber noch einen weiteren Grund sich mit autonomem Fahren näher zu zubeschäftigen. Und zwar betrifft das die Auslastung von PKWs. Laut http://www.zukunft-mobilitaet.net/13615/strassenverkehr/parkraum-abloesebetrag-parkgebuehr-23-stunden/ steht das durchschnittsliche Fahrzeit 95% der Zeit in einer Parkbucht. Aktuell sind in Deutschland 46 Mio PKW zugelassen. Das heißt, gleichzeitig sind davon nur 2,3 Mio auf den Straßen unterwegs. Das wiederum bedeutet, dass selbst das hochmotorisierte Land Deutschland nur einen Bedarf hat von effektiv vielleicht 3 Mio PKW, vorausgesetzt man würde diese Autos als Taxi nutzen. Das könnte man über autonome Steuerung erreichen. Wo man sich also ein Auto per Smartphone direkt vor die Haustür rufen lässt. Die Folge wäre nicht nur eine Einsparung von Metall zur Produktiv der vielen Autos, sondern man könnte auch riesige Mengen an Arbeitskraft einsparen. Denn wenn die Autos heute 95% der Zeit im Stau stehen heißt das auch, dass 95% der Autos fürs Parken gebaut werden. Slebst wenn man also die Produktiv der Automobile unverändert manuell durchführt, könnte man durch einen Autopiloten bereits sehr viel zum guten bewirken.

Der Witz wäre die Kostenrechnung für das ganze. Wenn man den Auslastungsgrad eines PKW erhöht, sinken dadurch natürlich die Kosten pro gefahrenem Kilometer. Das heißt, dass es für die Konsumenten sogar viel billiger wird, mit dem Auto irgendwohin zu fahren als heute. Und alles nur durch folgenden simplen trick. Man muss einfach dafür sorgen, dass die Autos nicht so wie heute parken, sondern dass sie permanent auf der Straße fahren. Das heißt, wenn man mit dem Auto vom Einkaufen nach Hause kommt, wird das Auto nicht etwa in die Garage gefahren damit es dort 14 Stunden am Stück wartet bis es wieder gebraucht wird, sondern das Auto hält kurz an, die Person steigt aus, und weiter geht die Fahrt.

Derartige Autos die Rund um die Uhr im Einsatz sind, könnte man sehr viel hochpreisiger bauen als heutige Modelle. Man könnte in das Auto Technik im Wert von 100000 EUR Und mehr verbauen ohne dass dadurch die Kosten ansteigen würden. Das Auto gehört dann nicht mehr einer Person oder einer Familie, sondern es gehört einem Konzern der es stundenweise vermietet. Um diesen Traum zu realisieren reicht eine simple Software, genannt Autopilot. Also eine Software die ähnlich wie beim Google Car, das Auto sicher durch den Verkehr navigiert.

CARSHARING
Warum sich bisher Carsharing nicht hat durchsetzen können ist simpel. Will man es machen wie bei einem Taxi braucht man einen Fahrer, der ist jedoch teuer. Will man Carsharing ohne Taxifahrer machen muss man das Auto an einen zentralen Stellplatz bringen, der ist jedoch zu weit weg. Wer bitteschön hat Lust, erst 10 km mit dem Bus zu fahren um sich dort ein Auto zu mieten? Richtig, Carsharing war bisher ein Flop und das ist gut so.

Wenn man jedoch autonomes Fahren mit Carsharing kombiniert — wie es gerade Uber ausprobiert — dann hat man die ultimative Lösung. Voraussetzung ist jedoch dass man die technischen Details des autonomen Fahrens beherscht. Nur wenn das Auto wirklich alleine fährt, kann man daraus ein Geschäftsmodell machen. Nur, um sich mal über die Dimensionen klarzumachen. Weltweit gibt es aktuell 1 Milliarde Autos. Davon sind geschätzt 600 Mio PKW die zu 95% der Zeit nutzlos in der Gegend parken. Wenn das auf autonomes Carsharing umstellt, könnte man mehrere hundert Millionen Autos einsparen. Und das beste ist, es würde niemand bemerken. Die individuelle Mobilität wäre die selbe wie heute auch.

Leider sieht es bei der tecnnischen Umsetzung derzeit noch nicht so gut aus. Soetwas wie eine OpenSource Software für das autonome Auto gibt es nicht. Ja nochnichtmal in einem Simulator wie Torcs gibt es aktuell Software die stabil funktioniert. Warum sich die Softwareentwickler noch nicht näher mit dem autonomen Auto beschäftigt haben ist unklar. Vermutlich weil das Problem aus sehr vielen Submodulen besteht und wenn man nicht alle angeht, wird sich das Auto keinen Zentimeter vorwärtsbewegen.

PROBLEME
Warum sind autonome Autos noch immer nicht realisiert? Was muss man tun, damit es irgendwann Realität wird? Der erste Schritt besteht darin, zunächst einmal nüchtern die Ist-Situation zu beschreiben. Obwohl es häufiger mediale Berichte gibt, wonach am autonomen Auto geforscht wird, und seit den 1980’er sogar Autos im Straßenverkehr unterwegs sind, die von einer Künstlichen Intelligenz gesteuert werden muss man sagen, dass die Ausgangslage extrem schlecht ist. Das fängt schon damit an, dass die Softwareentwickler noch nichtmal in der Lage sind sich eine Programmiersprache auszusuchen, in der sie einen Fahrsimulator schreiben wollen. Es gibt aktuell weder eine Simulations-Software, noch eine Künstliche Intelligenz und erst recht keine Vision Systeme. Zwwar wurde experimentiell schon viele Software entwickelt, doch die ist entweder kein OpenSource oder aber sie ist komplett wertlos. Das einzige was man heute out-of-the-box in einem Fahrzeug installieren kann, ist ein Linux basierendes Entertainment system wo auf dem Cockpit Youtube Videos abgespielt werden. Wie man jedoch das Auto steuert, darüber herscht selbst unter Informatikern das große Rätseln.

Ja schlimmer noch, es gibt keine Bücher, keine Podcasts und keine Internetforen in denen über autonomes Fahren diskutiert wird. Es mangelt also an der Infrastruktur um sich überhaupt mit dieser Technologie zu beschäftigen. Nur unter massivem Aufwand durch die DARPA gelang es im Jahr 2005 das weltweit erste Projekt aufzustellen, aber auch dort wurde keine Meta-Verfahren entwickelt um die Dinge voranzubringen, sondern es wurde das in die Autos verbaut, was sich die Leute im stillen Kämmerlein zusammengehackt haben.

Das Problem dürfte sein, dass in Sachen Autonomes Fahren der Leidensdruck zu niedrig ist. die Leute finden es normal, dass jährlich 1 Mio Leute auf den Straßen ihr Leben lassen, und sie haben sich damit abgefunden, dass ein Privat-PKW 23 Stunden von 24 Stunden in der Garage verbringt um zu ruhen.

Es gibt auch auch wenige Lichtblicke. Die Spielesoftware „Fernbus Simulator“ erfreut sich in der Community gr0ßer Beliebtheit.

Das fahrerlose Auto

Wie ist eigentlich der Ist-Zustand in Sachen driverless Car? Schenkt man den Massenmedien glauben, befindet sich die Technologie kurz vor dem Durchbruch. Es gibt lediglich noch kleinere Probleme mit der Verkehrzulassungsbehörde dann aber kann es losgehen mit dem selbstfahrenden Auto. Hersteller wie Mercedes und BMW sind aktiv an der Erforschung beteiligt … Leider ist das nur eine plumpe Illusion, sie beschreibt den gewünschten Zustand hat aber nichts mit der Realität zu tun. Die Wahrheit ist, dass weder die Technologie zur Verfügung steht sondern noch nichtmal begonnen wurde daran zu entwickeln.

Als Stand der Forschung muss man leider annehmen, dass Hobbybastler an ein Arduion Board 4 Räder dranmontieren, dann eine Webcam draufmontieren und dann irgendwie mit C++ versuchen, das Auto vorwärtszubewegen, womöglich noch unter Verwendung von obskuren neuronalen Netzen die auf nvidia Chips laufen. Irgendwas gelöst ist damit nicht, allenfalls ist das eine Demonstration wie es auf keinen Fall gemacht wird.

Ein selbstfahrendes Auto besteht aus einer großen Fülle an unterschiedlichen Komponenten die ähnlich wie bei einem Betriebssystem zusammenwirken. Und ist davon nur eine fehlerhaft, geht es nicht weiter. Von der Schwierigkeit her ist das Entwickeln der passenden Software 100x schwieriger als das Programmieren eines Linux-Kernels. Und nein, eine Software die erfolgreich funktioniert gibt es aktuell nicht. Was man jedoch tun kann ist ungefähr den Weg aufzuzeigen eine solche zu entwickeln. Zunächst einmal gilt es die Kernkomponente eines solchen Systems zu identifizieren, also ein Minimal-System zu entwickeln. Der Carolo-Cup ist ein Wettbewerb für autonome Autos bei dem die Teams auf einem Parcurs gegeneinander antreten. Obwohl dort nur Spielzeugauto in verkleinertem Maßstab eingesetzt werden, ist die Aufgabe noch immer zu anspruchsvoll. Was man zunächst einmal benötigt ist eine Light-Ausgabe des Carolo-Cup. Dieser findet auf einem virtuellen Parcurs statt, wobei die Vision Komponente unwichtig ist. Sondern es geht nur um die Steuersoftware als solche. Also um jenen Teil der letztlich die Lenkung und die Beschleunigung des Autos festlegt und der mit den Verkehrsregeln in Übereinstimmung gebracht werden muss.

Derartige Motion Control Komponenten sind das eigentliche Herzstück eines autonomen Autos. Und hier kann man versuchen, die Dinge nach vorne zu bringen. Üblicherweise wird soetwas iterativ entwickelt. Das heißt man startet mit „interactive control“ bei dem ein human-operator in-the-loop ist und steigert dann den Automatisierungsgrad. Die Herausforderung besteht darin, dass Wissen eines menschlichen Fahrers in ein Computerprogramm zu überführen. Üblicherweise wird dies als Begriffshierarchie durchgeführt, die ähnlich wie eine Klassenbibliothek ausgelegt ist. Es gibt Motion Primitive fürs Einparken, Abbiegen, am Stopschild anhalten, Wegeplanung usw.

Märchen über das autonome Fahren

[1] Hier ist sie wieder, die Behauptung dass selbstfahrende Autos mit Neuronalen Netzen und DeepLearning funktionieren würden. Mag sein, dass das von den Quellen her so belegbar ist. Nicht nur der obige Artikel schreibt das, sondern es finden sich auch viele wissenschaftliche Paper die das zu Protokoll geben. Wer jedoch schonmal versucht hat, auf seinem Arduinio RC ein neuronales Netz a la Caffe zu installieren und darüber versucht hat, das Auto zu steuern wird erkennen, dass neuronale Netze eher aufzeigen wie es auf keinen Fall gemacht wird. Auch Versuche, sogenannte LSTM Netze in einem Simulator wie TORCS einzusetzen um damit einen neuen Streckenrekord aufzustellen haben das Versagen dieser Technologie offenbar. Um es nochmal deutlich zu formulieren, neuronale Netze sind analoge Mustergeneratoren die nicht turing-mächtig sind und den Prozess des Software-Engineering nicht ersetzen können. Wer dennoch mit einer obskurven nvidia Hardware und nicht näher spezifizierten 16 Layer convolutional neural network einem Auto das fahren beibringen will sagt nichts anderes, als dass er zu faul ist echten code zu schreiben, keine Lust hat sich auf Bugsuche zu begegeben und überhaupt sich nur an ein Laienpublikum richtet jedoch nicht wirklich an der Thematik interessiert ist.

Ode an den Pofocs Podcast

Von ungefähr 2007-2011 gab es im deutschsprachigen Internet den Pofacs Podcast. Der RSS Feed von damals ist noch auf podcast.de einsehbar, allerdings kann man die verlinkten MP3 Files nicht mehr herunterladen. Eine Anfrage an archive.org erbrachte, dass zwar die html-Seiten gesichert wurden, nicht jedoch die ursprünglichen mp3-Dateien. Vermutlich ist der einzige Weg doch noch an die alten Folgen zu gelangen Bittorrent zu verwenden, aber das ist weniger empfehlenswert. Blicken wir doch etwas auf die genauen Hintergründe warum das Projekt eingestellt wurde. Wenn ich mich recht entsinne, lief Pofacs relativ gut an. Man hat damals im 2 Wochen Rhytmus neue Folgen zu produziert zu interessanten Themen zu denen bisher noch kein Podcast erschienen ist. Irgendwann sind die Autoren auf die Idee gekommen, einen Premium Dienst einzurichten weil sie sich darüber Feedback aus der Community versprachen. Dieser blieb aus und so ist das Projekt irgendwann im Sande verlaufen und auch die alten Folgen wurden offline gestellt.

Um ehrlich zu sein, kann ich die Motivation des Pofacs Team gut nachvollziehen. Nach dem Motto: wenn schon der Traffic Counter nicht so hoch ausfällt wie erhofft und es auch kein Feedback gibt, dann ist es Zeit das ganze abzubrechen und verbrannte Erde zu hinterlassen. Die einzigen die dazu die Macht haben, sind die Autoren selber, sie können entscheiden ob die Folgen online sind oder nicht.

Aber, das Problem ist folgendes. Computerthemen sind generell immer mit einer niedrigen Abrufzahl und einer niedrigen Feedback Frequenz ausgestattet. Hätten die Macher damals kein Podcast über OS/2 oder BSD gemacht sondern über Mode oder Kochen berichtet, wären die Abrufzahlen explodiert und der Premium Bereich wäre mit hunderten ja tausenden Community Members geflutet geworden. Das Problem mit Nischenthemen aus dem Bereich Hacking ist, dass egal wieviel Mühe man sich gibt, sie immer nur extrem wenig Leute anziehen. Und wenn man dann den Podcast noch auf Deutsch macht, reduziert sich die Anzahl nochmal. Aber selbst auf English sind Computer/Hacker Themen per se nicht für großen Traffic bekannt. Hier https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=EComStation mal die Wikipedia Abrufzahlen für den englischen Artikel zu ecomstation. Wikipedia steht bei Google immer auf Platz 1, und English ist die Weltsprache die von fast jedem verstanden wird, dennoch liegt der tägliche Traffic bei unter 200 Visits. Und auf die Wikipedia Seite greift bereits jeder zu, der sich nur halbwegs für das Thema interessiert. Bei einem 2 Stunden Podcast ist die Abrufzahl weitaus niedriger.

Ich will damit sagen, dass das Beispiel Pofacs nicht etwa die Ausnahme ist, sondern das ist die Regel. Sobald man ein Thema in einem Podcast aufbereitet was sich um Informatik und dort mit sehr speziellen Bereichen beschäftigt muss man von einer extrem niedrigen Abrufzahl ausgehen. Wenn man dann noch die Sprache auf Deutsch einschränkt, dürfte sich der Traffic mindestens halbieren. Kurz gesagt, man muss damit rechnen, dass weniger als 100 Leute den Podcast runterladen (in absoluten Zahlen über mehrere Jahre hinweg) und das es entweder gar kein Feedback gibt, oder komplett wertloses Feedback zurückkommt. Der Grund ist, dass Computer ein sehr spezielles Thema ist, womit man keine Massen begeistert.

Wirklich etwas ändern kann man daran nicht. Selbst wenn man das Projekt in allen Portalen gleichzeitig promoted und die besten Gäste der Welt einlädt (was beim Pofacs Projekt der Fall war), dann interessiert sich das Internet überhaupt nicht dafür. Das als Folge die Autoren irgendwann gefrustet sind, und nicht nur keine weitere Folgen produzieren, sondern auch die alten offline stellen ist die logische Konsequenz.

Angenommen man würde eine Neuauflage versuchen, also einen Pofacs 2.0 produzieren. Diemal nicht mit alternativen Betriebssystemen, sondern mit irgendeinem anderen Thema wie z.B. Arduino Hacking. Es würde exakt das selbe wieder passieren: die Autoren geben sich viel Mühe, schneiden den Audiostream, produzieren relativ viel Content und an Rückmeldung aus der Community gibt es exakt gar nichts. Das Problem ist das selbe wie beim ursprünglichen Pofacs Projekt. Die Anzahl der Leute die sich überhaupt für Computer ist minimal und bei einem Spezialthema wie Arduino sinkt die Anzahl noch weiter. Weitere Hörergruppen verliert man durch die Sprache deutsch, und wenn man dann in der Folge 1 vielleicht noch nicht supertoll war, springen weitere Hörer ab. Kurz gesagt, man kann ungefähr abschätzen, dass die Zahl der Stammhörer sich irgendwo unterhalb von 10 wird einpendeln wovon die Hälfte ohnehin den Content erstellt hat.

SYSTEMHELDEN
Zu Pofacs gibt es einen innoffiziellen Nachfolger http://systemhelden.com Dort geht es ebenfalls um Nischenthemen wie OpenSolaris und ähnlich wie bei Pofacs ist wohl das Feedback aus der Community nicht so gut wie erhofft. Jedenfalls sind die ersten 30 Folgen schon nichtmehr online, erst ab Folge 31 steht das ganze als mp3 im Netz. Leider ist das Projekt inzwischen eingeschlafen, die letzte Folge erschien in 2014 und seitdem gar nichts mehr. Ähnlich wie Pofacs auch, war der Podcast inhatllich super, es waren die richtigen Leute am Mic und die Themen waren spannend. Nur die Anzahl der Zuhörer war zu niedrig. In diesem Zusammenhang sei an den Konkurs der renomierten Data Becker Verlagsbuchhandlung erinnert die mit einem sehr guten Sortiment aber mit schwachen Absatzzahlen zu kämpfen hatte. Das ist schon irgendwie tragisch, das ausgerechnet die guten zuerst aufgeben. Währenddessen Podcasts die inhaltlich um einiges schlechter sind (ohne jetzt hier Namen zu nennen) bei den Charts immer vorne mit dabei sind.

Python mit C interagieren lassen

Dass Python die Sprache der Wahl ist um Prototypen zu erstellen braucht nicht mehr groß erläutert zu werden. Wann immer man es einsetzen kann ist es gegenüber jeder anderen Programmiersprache im Vorteil. Es gibt jedoch innerhalb des Python Universums eine Spielart die als sehr anspruchsvoll gilt und zwar die Verwendung von Code der nicht in Python geschrieben wurde. Der durchschnittliche Python Anwender hat damit weniger zu kämpfen, weil er vorhandene Librarys wie pygame einfach aus dem PyPi Repository installiert und dann benutzt. Aber was ist, wenn solche Librarys noch nicht erstellt sind?

Nach meiner Recherche gibt es aktuell zwei Optionen: ctypes und SWIG. Das wichtigste ist wohl wenn man sich zunächst um eine gute Dokumentation kümmert. Online habe ich nichts brauchbares gefunden, aber dafür findet man bei Google Books mehrere gute Dokumentationen dazu. Ich habe es zwar selbst noch nicht ausprobiert aber wenn ich es richtig verstanden habe, schreibt man eine Python Library und in dieser arbeitet man dann mit SWIG und ctypes, um dort dann C-Funktionen einzubinden wie z.B: SDL oder glibc.

Schaut man sich die existierenden Python Librarys sind (die extrem zahlreich sind) so ist es wohl grundsätzlich möglich, für jede C-Bibliothek ein Interface nach Python zu programmieren. Wie gesagt, der richtige Umgang mit SWIG dürfte innerhalb von Python bereits zu den Advanced Themen gehören, aber offenbar ist es möglich diesen Weg zu bestreiten. Der Vorteil ist, dass mit einem Schlag man darüber Zugriff erhält auf sämtliche Betriebssystemroutinen die noch dazu in der maixmalen Geschwindigkeit ausgeführt werden. Ich glaube, da liegt die eigentliche Stärke von Python. Objektorientierte Scriptsprachen gibt es neben Python noch viele andere wie z.B. Lua, Ruby, Javascript usw. Sie alle haben jedoch das Problem, dass sie nur eine eingeschränkte Funktion verfügen. Für Ruby gibt es beispielsweise keine gute Game-Engine, insofern ist das Interesse der Anwender an Ruby eher gering. Nicht so bei Python. Nach meiner Recherche wurde fast alles was sinnvoll ist, als Import-Library für diese Programmiersprache bereitgestellt und dadurch ist der mögliche Anwendungsrahmen sehr groß.

Man muss unterscheiden zwischen der Python Sprachspezifikation einerseits (also wie man konkret Programme schreibt) und den Tools mit denen man externe C-Biblitoheken anbindet, also ctypes und SWIG. Letzteres ist die eigentliche Stärke von Python und der Hauptgrund dafür warum es sich als Nummer 1 Scripting-Sprache etabliert hat.

Die meisten High-Level-Funktionen von Python wie die Plotting-Funktion, die Grafikausgabe in 3D, Physics-Engine, Abspielen von Mp3 usw. sind realisiert worden, indem externe bereits vorhandene C-Bibliotheken in Python aufrufbar sind. Die wenigsten Bereiche von Python wurden in Python selbst geschrieben, weil dafür die Sprache gar nichts schnell genug wäre.

Vom Ansatz her ist Python und C etwas sehr unterschiedliches. Das heißt, es gibt keinerlei Gemeinsamkeiten. Weder von der Syntax, noch vom Compilieren her und auch nicht was die Zielgruppe angeht. Die eigentliche Herausforderung ist nicht so sehr eine Scriptsprache zu erstellen sondern der Clou ist in SWIG und ctypes zu suchen. Ein derartiges Konzept ist bei anderen Programmiersprachen wie Java und C++ nicht vorhanden. Dort ist man dichter am ursprünglichen C dran und es gibt weniger Notwendigkeit einen Wrapper zu schreiben. Bei Java hat man im Grunde viele C-Bibliotheken nachprogrammiert in Java selber. Das heißt, es gibt einmal OpenGL vom Betriebssystem und dann gibt es dasselbe nochmal von Oracle/SUN. Bei Python hingegen war der Ansatz so, dass man eine möglichst große Distanz zu C aufgebaut hat. Man hat gleich von Anfang gesagt, dass man selber keine Compilersprache sein will und auch keine eigenen Bibliotheken haben möchte. Daraus ergibt sich automatisch die Notwendigkeit einen leistungsfähigen automatischen Wrapper namens SWIG verwenden zu müssen. Ohne diesen wäre Python komplett nutzlos. Ohne das mächtige import Kommando mit dem die meisten Python Programme eingeleitet werden, kann man in der Sprache selber fast gar nichts machen.

Warum erwähne ich das? Der Hauptgrund dürfte sein, dass Python als Programmiersprache sehr faszienierend ist. Mit 300 Lines of Code kann man bereits ein komplettes Computerspiel bauen, das geht mit keiner anderen Programmiersprache. Auf der anderen Seite ist auch C eine sehr faszinierende Sprache. Weil man dort hocheffizienten Code schreiben kann und sehr viele Frames per Second erzeugen kann. Auch das geht mit keiner anderen Programmiersprache. Ich habe einige Alternativen zu C ausprobiert, wie Java, C++, Go und Fortran. Aber keine erreicht die Performance von C.

Ich glaube, das eigentliche Problem besteht darin, dass es da draußen zu Hater von C und zu viele Hater von Python. Also Leute die sich abfällig äußern über C und es als veraltet bezeichnen, genauso wie es Leute gibt, die Python als Anfängersprache verunglimpfen. Ich glaube jedoch, dass jede Sprache für sich extrem mächtig ist in ihrer Nische und dort den Platz #1 innehat. Und das sich viele Probleme innerhalb der Informatik lösen ließen, indem man entweder auf C oder auf Python wechselt.

CTYPES
Eine minimal-Anleitung für ctypes gibt es auf http://stackoverflow.com/questions/5081875/ctypes-beginner Dort muss man zuerst ein C-Programm erstellen, dass dann mit speziellen Parametern (fpic shared) compilieren und kann dann über ctypes aus Python darauf zugreifen. Der Ablauf ist nicht ganz so einfach wie es Python Programmierer gewohnt sind, und manchmal gibt es noch Besonderheiten zu beachten, wenn man jedoch komplexere C-Bibliotheken erstellt ist das ein guter Einstieg. Ich will damit andeuten, dass mit ctypes und SWIG zwei sehr potente Tools zur Verfügung stehen um Python und C miteinander zu kombinieren und genau das wird sehr häufig eingesetzt. Ein wenig zu kritisieren ist jedoch die Dokumentation dazu. Ein Buch was sich speziell dieser Frage annimmt gibt es nicht, und die Online-Hilfe ist mehr als dürftig. Das Konzept als solches ist jedoch zukunftsfähig, man müsste es nur einer breiteren Öffentlichkeit vorstellen. Dann würde man auch vielleicht einige der Java, und C++ Fans zurückgewinnen können.

Nehmen wir mal an, man verfährt nach der obigen Anleitung und schreibt zuerst seinen C-Code und bindet den dann in die Python Anwendung ein. Der Vorteil ist, dass der C-Code mit nativer C-Geschwindigkeit läuft und all das kann was auch C kann. Gleichzeitig hat man mit Python jedoch ein User-Interface was an ein Einfachheit schwer zu überbieten ist. Wie man das ganze objektorientiert gestaltet ist derzeit nicht klar. Aber ich glaube das geht auch auf diese Weise. Weil es ja mehrere Python-Libraries gibt, die objektorientiert funktionieren. Man man mit so einer Pipeline noch weitere Programmiersprachen wie Java oder C++? Eher unwahrscheinlich. Wenn man dann noch im C-Code Threading einsetzt un den -O3 Compilerschalter kann man High-performance-Anwendungen betreiben.

Eim Performance-Vergleich zwischen Python pur und Python plus C-Library hat http://www.maxburstein.com/blog/speeding-up-your-python-code/ angestellt. Danach erreicht man mittels ctypes einen Performancegewinn um den Faktor 30. Anders formuliert, Python ist 30x langsamer als C.

CFFI
Eine weitere Methode Python mit C-Code anzureichern ist CFFI. Die Entwickler von pymunk benutzen es aktiv http://www.pymunk.org/en/latest/advanced.html Um damit ihre C-Library für Python User zugänglich zu machen.

Insgesamt muss man festhalten, dass es im Bereich der Python Schnittstellen relativ viel Chaos gibt. Insgesamt existieren mindestens 5 Wege wie man Python und C zusammenbringt, die noch dazu sehr schlecht dokumentiert sind. Aber, mit Blick in 10 Jahren dürfte sich das Problem entschärft haben weil die Programmierer eher einen Überblick erhalten was geht und was nicht. Wenn man das Angebot etwas strafft und die Dokumentation verbessert hat man eine sehr gute Programmierumgebung. Im Gegensatz dazu sind andere Programmiersprachen wie Java oder C# auf den ersten Blick sehr konsistent aufgebaut. Haben aber den Nachteil, dass sie sich in einer technologischen Sackgasse befinden. Kurz gesagt, ich glaube dass die Mischung Python + C für systemkritische Software gedacht ist, während Java und Co zum rumspielen und Lernen entwickelt wird.

Performance von ctypes ist überragend

Die neu entdeckte ctypes Schnittstelle in Python habe ich einer näheren Untersuchung unterzogen. In C wird zunächst eine Primzahlen Funktion definiert, die eine große Last auf der CPU erzeugt. Diese wird dann in eine Binär-Library kompilert und über Python eingebunden. Dann wird die Ausführungszeit verglichen. Die Laufzeit mit ctypes ist dieselbe als wenn man das C-Programm solo startet. Zur Verdeutlichung hier der Sourcecode:

/*
  Kompilieren:
    gcc -shared -Wl,-soname,prim -o prim.so -fPIC prim.c
  
  Python:
    import ctypes
    prim = ctypes.CDLL('/tmp/1/prim.so')
    prim.main()
  
  Performance: 
    gcc real	0m6.557s
    python real	0m6.578s
*/

#include <stdio.h>
int main() {
  int flag;
  for (int i=0;i<300000;i++) {
    flag=0;
    for (int a=2;a<=i/2;a++) {
      if (i%a==0) { 
        flag=1;
        break;
      }
    }
    if (flag==0) printf("%d\n",i);
  }
  return 0;
}

Natürlich ist das ganze nicht wirklich eine Neuigkeit weil das PyPi Repository wo bereits sehr viele C-Librarys gewrapped wurden ja bereits existiert. Das heißt, dass man C mit Python koppeln kann, haben schon andere Leute herausgefunden. Interessant daran ist jedoch, dass es zukunftsfähig ist. Das heißt man kann davon ausgehen, dass Python eine ausgezeichnete Perspektive besitzt. Weil man auch eigene C-Programme leicht dafür aufbereiten kann. Wenn jedoch Python Programme auf C-Bibliotheken zugreifen, ist die Programmiersprache unschlagbar. C ist zweifellos die performanteste Sprache überhaupt.

Ctypes, SWIG oder CFFI dürfte einer breiten Öffentlichkeit nahezu unbekannt sein. Wir haben es also mit einem sehr leistungsfähigen Konzept zu tun, was gleichzeitig unbekannt ist. Stattdessen denkt der Mainstream, dass Java oder C# die Zukunft wäre.