Python vs C++

C++-Freak schrieb:
> Jetzt will ich mich über Python schlau machen und lese dass man mit
> Python viel schneller und einfacher programmieren kann. Dann lese ich
> irgendwo dass in Python-geschriebene Programme 100-400 mal langsamer ist
> als C++. Ist das korrekt?

Das könnte schon hinkommen. Python ist eine rein interpretierte Sprache.

> Ich erinnere mich wie ich in 2000er Jahre mit Delphi oder Visual Basic
> angefangen habe und war dann genervt dass 3D-Grafik zu langsam lief. Ich
> wollte damals ein 3D-Engine für Computerspiele programmieren. Deshalb
> bin ich auf C++ umgestiegen. 20 Jahre später scheint Python so ein Hype
> zu sein. Raspberry Pi mit Python, TensorFlow mit Python. Warum
> eigentlich Python? Ist doch genauso dumm wie Delphi und VB?

Na weil…

C++-Freak schrieb:
> man mit Python viel schneller und einfacher programmieren kann.

Ein Programm muss selten so schnell wie möglich und meist nur so schnell 
wie nötig sein. Wenn ich einen Codegenerator schreibe, der aus einer 
Konfigdatei ein Stück C-Code generiert, wird der Löwenanteil der Zeit 
für File-I/O draufgehen. ob der Rest davon jetzt 100 µs oder 100ms 
braucht, spielt für mich keine Rolle.
Ein Computerspiel würde ich jetzt nicht unbedingt komplett in Python 
schreiben, wenn es die Fähigkeiten der Hardware ausreizen soll. Aber 
auch dort können Teile durchaus in Skripting-Sprachen geschrieben 
werden. Das  hat man schon in den 90ern so gemacht.
Siehe https://de.wikipedia.org/wiki/QuakeC
Denn auch bei Programmen, die performant sein müssen, ist immer nur ein 
(manchmal sehr kleiner) Teil des Code wirklich zeitkritisch. Beim Rest 
kann man darauf verzichten und etwas verwenden, das eher die Effizienz 
beim Programmieren in den Vordergrund als die Effizienz bei der 
Ausführung.
Bei TensorFlow z.B. wird der rechenaufwändige Teil in der GPU in Cuda 
gerechnet. Der Python-Code kümmert sich nur darum, dafür alles 
vorzubereiten und das Ergebnis abzuholen.

C++-Freak schrieb:
> wenn ich rechenintensive Codes schreiben will, kann man das in C++
> schreiben und dann in Python ausführen?

Ja. Beim von Dir bereits erwähnten TensorFlow bspw. werden die 
rechenintensiven Teile natürlich auch nicht in Python implementiert.

https://docs.python.org/3.7/extending/extending.html

C++-Freak schrieb:
> Für C++-Programmierer sieht das nach noch mehr Drecksarbeit aus, damit
> es für Pythoner einfacher wird. Ich bin begeistert.

Sicher, letztlich steckt natürlich genau das dahinter: Die geheime 
Weltverschwörung der Pythoner hat sich da in Wahrheit natürlich nur 
einen raffinierten Masterplan ausgedacht, wie sie die Herrenrasse der 
C++-Programmierer unterjochen kann.

Das einzige Problem bei diesem diabolischen Plan ist, dass alle paar 
Jahre doch mal ein bornierter C/C++-Programmierer vorbeikommt, der 
längst verstanden hat, dass jede anderer Programmiersprache ausser dem 
von ihm gelernten C/C++ völlig überflüssig und reine Zeitverschendung 
ist.
Derart clevere Zeitgenossen durchschauen den Plan natürlich sofort, und 
sind daher eine grosse Bedrohung. Just in diesem Moment klingelt bereits 
das rote Telefon im unterirdischen Pythoner-Hauptquartier - gleich 
debattieren sie, wie sie Dich eliminieren können...

Python ist eine extrem gute Frontend-Sprache, wegen ihrer Flexibilität 
und Ausdrucksstärke. Es ist keine gute Sprache, um Low-Level-Algorithmen 
zu implementieren.

Ehrlich gesagt ist es in C++ ein bisschen ähnlich. Viele Bibliotheken 
heutzutage ertrinken in Template-Metaprogrammierung, die man in seinem 
eigenen (User/Application-Level) Code so nie haben wollen würde, weil 
sie für den durchschnittlichen Leser völlig unlesbar und unwartbar ist. 
Es wird so gesehen eine andere Sprache (C++-Metaprogrammierung) 
verwendet, um eine API zu bauen, die bequem von klassischem C++-Code 
aufgerufen werden kann.

C++-Freak schrieb:
> wenn ich rechenintensive Codes schreiben will, kann man das in C++
> schreiben und dann in Python ausführen?

Das wird schon so mit der numerischen Python Bibliothek numpy gemacht.

C++-Freak schrieb:
> Jetzt will ich mich über Python schlau machen und lese dass man mit
> Python viel schneller und einfacher programmieren kann.

Das trifft zu. Man muss dabei aber berücksichtigen, dass man mit Python
etwas mehr Zeit ins Testen steckt, da viele Programmierfehler, die in
C++ schon vom Compiler erkannt werden, in Python erst zur Laufzeit
aufgedeckt werden.

> Dann lese ich irgendwo dass in Python-geschriebene Programme 100-400
> mal langsamer ist als C++. Ist das korrekt?

Der Faktor 400 ist aber schon die absolute Obergrenze. Meiner Erfahrung
nach liegt der Geschwindigkeitsfaktor eher im Bereich von 20 bis 100.
Bei Verwendung von kompilierten Bibliotheken für rechenintensive
Aufgaben (Numpy, OpenCV, TensorFlow usw.) kann man schon sehr dicht an
die Ausführungsgeschwindigkeit von C++ (bspw. Faktor 1,5) herankommen.

Es gibt eine ganz einfache Regel für schnellen Python-Code: Es dürfen
keine Schleifen mit hunderttausenden oder noch mehr Durchläufen sichtbar
sein. Es fällt am Anfang etwas schwer, auf die liebgewonnenen Schleifen
zu verzichten. Mit der Zeit gewöhnt man sich aber einen entsprechenden
Programmierstil an.

> 20 Jahre später scheint Python so ein Hype zu sein.

Der Hype war schon von 20 Jahren, heute ist Python Mainstream.

> Ich erinnere mich wie ich in 2000er Jahre mit Delphi oder Visual Basic
> angefangen habe und war dann genervt dass 3D-Grafik zu langsam lief.
> Ich wollte damals ein 3D-Engine für Computerspiele programmieren.
> Deshalb bin ich auf C++ umgestiegen.

Das klingt ein wenig wie: "Wenn der Bauer nicht schwimmen kann, ist die
Badehose schuld" :)

mh schrieb:
> Yalu X. schrieb:
>> Der Faktor 400 ist aber schon die absolute Obergrenze. Meiner Erfahrung
>> nach liegt der Geschwindigkeitsfaktor eher im Bereich von 20 bis 100.
>> Bei Verwendung von kompilierten Bibliotheken für rechenintensive
>> Aufgaben (Numpy, OpenCV, TensorFlow usw.) kann man schon sehr dicht an
>> die Ausführungsgeschwindigkeit von C++ (bspw. Faktor 1,5) herankommen.
>
> Das hilft aber leider nur, wenn die Bibliotheken genau das enthalten,
> was man braucht.

Viele Funktionen der Standardbibliothek, Numpy und einiger anderer
Bibliotheken sind diesbezüglich sehr generisch, so dass – zumindest für
bestimmte Klassen von Anwendungen – die Chancen recht groß sind, dass
man darunter etwas Passendes findet.

> Wenn es nicht enthalten ist, muss man entweder Tricks anwenden, die
> schwer zu verstehen sind, oder sie in C, C++ oder Fortran selbst
> schreiben, oder mit schlechter Performance dank extra Schleifen und
> unnötigen Zwischenergebnissen leben.

Natürlich ist Python kein allumfassender Ersatz für C++. Wenn für eine
bestimmte Anwendung in den verfügbaren Bibliotheken zu viele Dinge
fehlen und diese Dinge in Python zu langsam sind, dann ist Python eben
nicht die richtige Sprache für diese Anwendung, und man entwickelt sie
stattdessen in C++. Schön, dass es beide Sprachen gibt und beide nichts
kosten :)

Wichtig ist halt, dass man an keiner der beiden Sprachen zu sehr
festklebt, sonst legt man sich unnötigerweise selber Steine in den Weg.

mh schrieb:
> Wenn es in C++ einen brauchbaren Ersatz für numpys multidimensionale
> Arrays geben würde, würde ich auf python verzichten und nur noch C++
> nutzen.

Der Typ cv::Mat aus der OpenCV ist dem numpy.array in den verfügbaren
Features und dem internen Aufbau sehr ähnlich.

  https://docs.opencv.org/4.1.0/d3/d63/classcv_1_1Mat.html

Im Python-API der OpenCV treten cv-Mat-Objekte als numpy.array-Objekte
in Erscheinung, was deren Ähnlichkeit ebenfalls unterstreicht.

Schade, dass es nun einen Python-User weniger gibt ;-)

Ich möchte noch 2 Argumente im Widerstreit compilierter vs 
interpretierter Sprachen (als Generalisierung des Gegensatzes Python vs 
C++) einbringen.

1. Relevanz absoluter Performance
Ich habe schon wirklich viele Knobelaufgaben, z.B. von projecteuler, 
gelöst. Natürlich habe ich mir oft "schnellere" Ausführung gewünscht. 
Die Lösung war aber fast immer ein schnellerer Algorithmus, der dann um 
Größenordnungen besser war. Ein Faktor 5, 10 oder 20 fällt praktisch 
kaum ins Gewicht.

Das heißt nicht, dass es nicht auch solche Probleme gäbe: Wenn man 
Numbercrunching machen muss tut man das natürlich in eine maschinennahen 
Sprache, so wie die Python-Bibliotheken das auch tun. Wenn es wirklich 
hart auf hart kommt müsste man sich aber auch überlegen, wie man 
Vektorisierung der CPU oder Grafikkarten einbindent. Also doch wieder 
eine Algorithmen-Lösung...

Miese Performance von Allerweltscode liegt i.d. Regel nicht an der 
schlechten Sprache.


2. Vorteile "interpretierter" Sprachen.
Es gibt eine ganze Reihe von Optimierungen, die einer kompilierten 
Sprache nicht zugänglich sind und die nur mit einem optimierenden 
Interpreter oder JIT-Compiler nutzbar sind.

Ein Beispiel aus der C++-Welt sind hier virtuelle Methoden. Wenn ich in 
C++ ein Objekt ableite und dann eine virtuelle Methode aufrufe, so muss 
immer zuerst im virtual method table nachgeschaut werden, welcher Code 
ausgeführt werden soll.
In einer interpretierten Sprache passiert das natürlich genauso (nur 
halt interpretertypsich ein bischen langsamer). Ein integrierter 
Profiler kann aber rausfinden, dass in den ersten paar hundert Aufrufen 
immer die gleiche Methode aufgerufen wurde. Jetzt kann ein JIT-Compiler 
optimierten Maschinencode für genau diesen Default-Fall bauen. Sollte 
doch mal ein anderes Objekt kommen gibt immer noch den Interpreter als 
Fallback.

Analog wird auch der Zugriff auf Objektmember optimiert: Interpretierte 
Sprachen nehmen da i.d. Regel (langsame) Dictionaries. Der JIT-Compiler 
ersetzt das irgendwann durch relative Zugriffe, wie in einem C-struct.

Anderes Beispiel: Ob sich Loop-Unrolling lohnt kann ein Profiler, der 
die tatsächliche Ausführung beobachtet, oft besser beurteilen als ein 
Compiler, der nur in seltenen Fällen rausfinden kann wie oft eine 
Schleife laufen wird.


Langer Rede kurzer Sinn: Mit der Performance ist es nicht so einfach. C 
und C++ sind zwar oft schneller, aber nicht immer.
Und der Performance-Unterschied ist oft egal.

C++-Freak schrieb:
> wenn ich rechenintensive Codes schreiben will, kann man das in C++
> schreiben und dann in Python ausführen?

Es gibt im Prinzip zwei Varianten: Einmal die Variante, wo das 
Hauptprogramm in Python geschrieben ist und rechenintensive Teile als in 
C++ implementierte Module bereitgestellt sind. Oder die umgekehrte 
Version, wo das Programm an sich in C++ geschrieben ist und bestimmte 
Teile, die nicht so zeitkritisch sind, aber flexibel per Skripting 
anpassbar/erweiterbar sein sollen, dann in Python geschrieben sind und 
in einem im Programm eingebetteten Interpreter ausgeführt werden.

Stefan S. schrieb:
> Yalu X. schrieb:
>> Schön, dass es beide Sprachen gibt und beide nichts
>> kosten :)
>
> Noch schöner dass es auch andere Sprachen gibt, die die Vorteile von
> Python und C++ recht gut vereinen! Und die auch nichts kosten ausser der
> Arbeit sie zu lernen. (OK, und der Arbeit Bibliotheken und Bindings
> eventuell selbst schreiben zu müssen, weil sie noch nicht existieren.)

Und die wäre(n)?

Carl D. schrieb:
> Stefan S. schrieb:
>> Yalu X. schrieb:
>>> Schön, dass es beide Sprachen gibt und beide nichts
>>> kosten :)
>>
>> Noch schöner dass es auch andere Sprachen gibt, die die Vorteile von
>> Python und C++ recht gut vereinen! Und die auch nichts kosten ausser der
>> Arbeit sie zu lernen. (OK, und der Arbeit Bibliotheken und Bindings
>> eventuell selbst schreiben zu müssen, weil sie noch nicht existieren.)
>
> Und die wäre(n)?

Julia

https://julialang.org/