Lohnt es sich noch C++ zu lernen?
-
Sagt auf alle Fälle bescheid, wenn das klappt. Die Ausgabe brauche ich dann ausnahmsweise auch mal.
Zum Thema:
Ich hatte auch mal eine Wavelet Toolbox, die war -man höre und staune- als VB -Script im Exel implementiert und hat meine C++ Variante geschwindigkeitsmäßig um Längen geschlagem. Ich bin weit davon entfernt nun zubehaupten C++ wäre langsamer nur weil mein algo etwas hinkt ( Habe mein VS auch immer noch nicht gegeg den Exel Makro - Editor eingetauscht
).
Die meisten Grundlegenden Erkenntnisse, wie man gut entwickelt sind doch eh Sprachunabhängig und eher an grundlegende Konzepte gebunden. Man kann in jeder Sprache gute und schlechte Software schreiben. Unter umständen bricht man sich aber bei manchen Projekten mit der falschen Sprach- (oder Tool-) Wahl ganz schön einen ab und macht sich das Leben schwer.
-
den c't Benchmark kenne ich nicht, mit Minibenchmark meinte ich eigentlich den hier:
#include <iostream> int main() { for( int i(0); i < 100000; ++i) { std::cout << "Das ist der "<<i<<"te Schleifendurchlauf"; } }Ich verstehe nicht wieso Java da schneller ist. Also ich benutze in meinen Programmen oft for-Schleifen und dann sollen die lahm sein.
Auch ist dieses Programm absolut minimal, da kann man nichts mehr optimieren oder falsch machen.Wieso ist dein Java-Programm hier schneller, das ist mir absolut unverständlich.
-
weil ostream operatar << viel komplexer ist als System.out.println
-
complex schrieb:
weil ostream operatar << viel komplexer ist als System.out.println
System.out.println ist noch viel lahmer. Wenn du weiter vorne guckst, dann wirst du feststellen, dass ich das ganz anders im Javaprogramm gemacht habe.
Wie gesagt: Jede Sprache hat Schwachstellen. Eine Schwachstelle von C++ ist halt hier gezeigt worden. Wenn du IO in C++ machen möchtest, die performant sein soll, dann mach das ohne "<<". Das kannst du aus diesem Benchmark lernen.
-
wie gesagt, C++ ist ein Sprachstandard. Man kann da schlecht etwas zum Thema Performance sagen
Vielleicht ist ja der << operator bei einer anderen Implementierung schneller.
-
kingruedi schrieb:
Vielleicht ist ja der << operator bei einer anderen Implementierung schneller.
Ich habe noch keine gesehen. Erinnerst du dich an den Microbenchmark, mit dem wir vor langer Zeit mal ein bischen Java, C# und C++ vergleichen wollten? Im C#-Forum? Da war der << Operator unter anderem auch eine Performancebremse. ...und da hatten wir diverse Compiler ausprobiert.
-
mir geht es um was anderes. Wir sollten nicht versuchen Konzepte mit Implementierungen zu vergleichen. Das ist eben das mit den Äpfeln und den Birnen
-
sehe ich auch so.
Optimieren war nicht Ziel des Vergleiches. Siehe anderen Thread
-
kingruedi schrieb:
mir geht es um was anderes. Wir sollten nicht versuchen Konzepte mit Implementierungen zu vergleichen. Das ist eben das mit den Äpfeln und den Birnen
Wir vergleichen hier ausschließlich die Performance von Implementierungen. ...und wenn du aus dem Benchmark nicht ersehen kannst, dass der << Operator i.d.R. nicht sehr performant implementiert ist (siehe den ganz alten Benchmark), dann wirst du ihn halt weiter nutzen und deine Programme bleiben lahm. Bei dem alten Benchmark war dein Programm ja auch nicht gerade schnell. Mich interessiert es eigentlich garnicht, wenn mir jemand sagt, dass etwas nicht konzeptionell lahm ist. Mich interessiert nur, wie es wirklich ist.
Java ist zum Beispiel i.d.R auch etwas langsamer als C++. Das ist aber kein Konzept der Sprache und steht auch nicht in der Sprachspezifikation. Das hat allein etwas mit der Implementierung der Sprache zu tun.
-
Das ist aber kein Konzept der Sprache und steht auch nicht in der Sprachspezifikation. Das hat allein etwas mit der Implementierung der Sprache zu tun.
jop, deswegen kann man sagen, die J2<blubblub>-Edition ist beim benutzen von foo so und so viel langsammer als der G++ (natürlich sollte man den Code dazu zeigen, weil wir ja spätestens durch den Ct Artikel gesehen haben, dass man durch schlechten Code alles schlecht machen kann :)).
Man kann aber nicht sagen J2<blubblub>-Edition ist langsammer als C++. Das geht nicht!
Es gibt unterschiedliche Java Implementierungen (ja, es gibt auch Java Compiler und ich hab sogar mal was von einer CPU gehoert, die ByteCode verstehen soll) und es gibt unterschiedliche C++ Implementierungen.
Deswegen sollten wir uns darauf einigen, dass C++ weder langsammer noch schneller als Java ist, da man keine wirkliche Geschwindigkeit aus den Spezifikationen ableiten kann!
Aber ich halte nicht viel von dem ganzen Benchmark quatsch etc. Wenn ich eine Anwendung habe und in der Anwendung ein Performance Problem, dann nehm ich mir nen Profiler und schau wo es hackt. Wenn es dann eben in C++ der << Operator ist, dann ersetz ich dass durch andere Methoden, genauso wie ich das bei Java machen würde, wenn ich das Problem mit System.out.println haben wuerde.
So benchmarks sind weit von der Realitaet entfernt und sagen nichts aus. (Sei mal ehrlich, bei welchem Programm bist du an der Performance von System.out.println gescheitert?)
Im Endeffekt kommt es bei Java vs. C++ nicht darauf an, dass es eine C++ Implementierung gibt, die 10 mal schneller Zufalls float Werte sortieren kann.
Ob man C++ oder Java lernt ist eigentlich auch egal, weil man im Endeffekt die Werkezeuge (Sprachen sind Werkzeuge) nicht aus dem Grund die Werkzeuge zu benutzen benutzt (natürlich am Anfang schon, um sich in die Sprache einzuarbeiten), sondern weil man damit ein Problem lösen will und man dann entscheiden sollte, welche Programmiersprache man nimmt (es gibt auch Probleme, fuer die Java und C++ ungeeignet sind und/oder es bessere Wege gibt).
Bei Java und C++ hat man eben das Problem, dass die Sprachen sich sehr aehnlich sind und man deswegen eher die Bereiche überschneiden in denen man die Sprachen einsetzt. Deswegen kommt es wohl staendig zu diesen klein Kriegen.