Hallo, ich programmierte hauptsächlich C++ für Mikroprozesoren (Arduino) und früher auch für PC-Programme. 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? 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?
C++-Freak schrieb: > schlau machen Und wo hast Du Dich die letzten 20 Jahre versteck? Auf einer einsamen Insel ohne Kontakt zur Aussenwelt? Das Thema Programmiersprachen mag ein weites Feld sein, aber es ist doch nun wirklich oft genug durchgekaut worden.
Beitrag #5973841 wurde von einem Moderator gelöscht.
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.
wenn ich rechenintensive Codes schreiben will, kann man das in C++ schreiben und dann in Python ausführen?
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
Für C++-Programmierer sieht das nach noch mehr Drecksarbeit aus, damit es für Pythoner einfacher wird. Ich bin begeistert.
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...
Offensichtlich kommt man mit Python irgendwie anders und anderswohin als mit achsoviel C/C++Drecksarbeit. Die Metriken für anders und anderswohin wollen halt erst begriffen werden. Dies verlangt einem halt ein paar Braincycles ab, welche nicht wirklich frei sind solange sie eben mit C/C++ belegt sind. Jeder der will, darf mit C/C++Drecksarbeit glücklich bleiben. Keiner wird gezwungen auf Modula2/Ada/Python/Rust/Lua/... aufzusteigen. N.B.: man kann immer schnelle Programme welche in der einen Programmiersprache gut geschrieben sind, mit langsamen Programmen welche in einer andern Programmiersprache schlecht geschrieben sind vergleichen. N.B.2: im Beispielfall von 3D-Grafik anno 2000 hat es bestimmt an der Sprachwahl Delphi/BASIC gelegen dass das Ergebnis unbefriedigend war und keinesfalls an der eingebundenen lib(s) für 3D. Auch keineswegs an den umgesetzten Algorithmen. Echt jetzt. N.B.3: eine der "C/C++Drecksarbeiten" IST Python selbst. Dass C/C++Programmierer überhaupt auf solche Gedanken kommen ist unerhört! Muss wohl einer aus 'ner Anstalt ausgebüxt sein als die C/C++TalibanAnstaltsaufsicht gerade zu konzentriert auf ihr Code war... N.B.4: C/C++ ist ja soo gut, dass der Arbeitsmarkt nur so überschwemmt ist von guten C/C++Programmierern. Es gibt in der RealenWelt fast kein mangelhafter C/C++Code der zu korrigieren wäre, in C/C++ implementierte Produkte glänzen durchs Band mit fast absoluter Fehlerfreiheit. "Bedarf für andere Programmiersprachen" ist ein Oxymoron - gerade deswegen.
C++-Freak schrieb: > wenn ich rechenintensive Codes schreiben will, kann man das in C++ > schreiben und dann in Python ausführen? Nein, ausgerechnet wer diese Frage stellt eben nicht.
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: > 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? Ja, bei der ersten Aussage geht es um die Arbeitszeit des Programmierers. Bei der zweiten geht es um die Rechenzeit der Programme auf der Hardware. D.h. die 3d Engine schreibst du am besten in C++. Aber die Gamelogik, in der dein Avatar eine Kiste öffnet und geprüft werden muss, ob er überhaupt den passenden Schlüssel hat, den schreibst du in Python.
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: > Warum > eigentlich Python? verstehe ich auch nicht. Zumal sie ihre Libs in C++/... schreiben. Und dann eine Python-Schnittstelle anbieten.
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" :)
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. 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. Yalu X. schrieb: > 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. Und man muss wissen, welche Bibliotheksfunktionen ohne Schleifen oder andere langsame Konstrukte auskommen. 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 python Vorteil in der Entwicklungszeit geht bei mir verloren, wenn ich Teile in C++ oder Fortran reimplementieren muss, damit sie schnell genug sind.
C++-Freak schrieb: > Für C++-Programmierer sieht das nach noch mehr Drecksarbeit aus, > damit > es für Pythoner einfacher wird. Ich bin begeistert. für sowas gibt es swig, das verspricht das Binding zu machen für scriptsprachen.
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 ;-)
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? Frag mal c-hater
Yalu X. schrieb: > 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. Hmmm. Ich bin mir sicher, OpenCV angeguckt zu haben. Muss ich wohl nochmal gucken, ob es da andere Probleme gab oder gibt. Ich sollte an der Stelle auch noch erwähnen, dass "etwas wie numpy.array in C++" eigentlich noch vernünftige Expression-Templates haben sollte, um das volle Optimierungspotential ausnutzen zu können. Ich hatte vor einiger Zeit große Hoffnung in xtensor. Aber das ist einfach nur grausam. Yalu X. schrieb: > Schade, dass es nun einen Python-User weniger gibt ;-) Noch bezahlen mich genug Kunden für uralt-fortran oder idl nach python Konversionen.
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.
Tilo R. schrieb: > 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. Alles was du an Beispielen für einen Interpreter mit JIT bringst, können manche C++ Compiler auch. Es erfordert allerdings, dass man Laufzeitstatistiken erstellt. Dafür müssen dann nicht während der Laufzeit aufwendig Teile des Programms compiliert werden.
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.
Tilo R. schrieb: > 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. Eine wirklich beeindruckende Verbesserung der Performance habe ich durch PGO gegenüber eines normalen Kompilats noch nicht erreicht. Die anderen (rechenintensiven) Optimierungen scheinen also deutlich mehr zu bringen. Das (und/)oder die Prädiktoren funktionieren einfach hinreichend gut.
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.)
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)?
:
Bearbeitet durch User
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/
Carl D. schrieb: >> 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)? Hier kann natürlich nur Tcl gemeint sein.
Helwein V. schrieb: >> Und die wäre(n)? > > Julia > > https://julialang.org/ Ja, Julia ist natürlich ein sehr interessanter Kandidat, wenn der Schwerpunkt in Richtung von Matlab Anwendungen geht und einem die virtuelle Maschine nicht stört. Dass mein Favorit derzeit eher Nim ist ist ja eh kein Geheimnis, die Community ist halt noch immer sehr klein. Crystal habe ich ich die letzten Jahre nicht viel beobachtet, ist wohl ähnlich klein wie Nim.
Stefan S. schrieb: > (OK, und der Arbeit Bibliotheken und Bindings > eventuell selbst schreiben zu müssen, weil sie noch nicht existieren.) Ein durchdachter Plan, zumal heutzutage bei den "üblichen" HPC-, BigData- oder KI-Projekten das Neuentwickeln der Bibliotheken locker >90% des Aufwands ausmachen würden...
John Doe schrieb: > Stefan S. schrieb: >> (OK, und der Arbeit Bibliotheken und Bindings >> eventuell selbst schreiben zu müssen, weil sie noch nicht existieren.) > > Ein durchdachter Plan, zumal heutzutage bei den "üblichen" HPC-, > BigData- oder KI-Projekten das Neuentwickeln der Bibliotheken locker >>90% des Aufwands ausmachen würden... Was in diesen Feldern aber unnötig ist, da diese Bibliotheken in C, C++, Fortran, CUDA, OpenCL geschrieben sind und Python nur fürs Frontend verwendet wird. In Julia lässt sich allerdings auch C-, Fortran-, Python-, R-Code direkt ausführen.
C++-Freak schrieb: > mit Delphi oder Visual Basic > angefangen habe und war dann genervt dass 3D-Grafik zu langsam lief. spätestens da merkt man das Du Unsinn schreibst;-) Es gibt schnelle 3D Engines für Delphi und vermutlich auch für Basic.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.