mikrocontroller.net

Forum: PC-Programmierung Python vs C++


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: C++-Freak (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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?

Autor: Stefan S. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: C++-Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn ich rechenintensive Codes schreiben will, kann man das in C++ 
schreiben und dann in Python ausführen?

Autor: Joachim S. (oyo)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: C++-Freak (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Für C++-Programmierer sieht das nach noch mehr Drecksarbeit aus, damit 
es für Pythoner einfacher wird. Ich bin begeistert.

Autor: Joachim S. (oyo)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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...

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C++-Freak schrieb:
> Warum
> eigentlich Python?

verstehe ich auch nicht.

Zumal sie ihre Libs in C++/... schreiben. Und dann eine 
Python-Schnittstelle anbieten.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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" :)

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: imonbln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo R. (joey5337) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Helwein V. (forgoden)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John Doe (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.