Lohnt es sich noch C++ zu lernen?

Gregor

Sgt. Nukem schrieb:

Bist Du Dir sicher daß die 100% (!!) Java sind?!?!

Wenn man davon absieht, dass einige dieser Spiele Bibliotheken nutzen, mit denen man OpenGL oder Direct3D von Java aus nutzen kann (LWJGL, JOGL, Gl4Java, Java3D,...), dann sind diese Spiele nach meinen Informationen zu 100% aus Java.

Naja, ist Definitionssache, ob das 100% Java ist. Nach Sun kann ein Programm, welches Java3D nutzt durchaus als 100% Java gelten. Andere sehen das enger.

BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?

RHBaum

welche "Performance-Fehler" gemacht wurden

Hehe, beim ersten mal grob ueberblaettern, dacht ich auch mich trifft der Schlag!
Meine Vermutung ist, die Performance Bremse ist das CObject, von dem alle Elemente abgeleitet sind. Strittig ist die Frage, ob das, wie im Text behauptet, uebliches Vorgehen ist !
Also ich leite meine Datenobjecte nie von CObject ab .... ! (arbeite auch kaum mit der MFC). Weiterhin fehlt auch die aussage, ob die MFC statisch oder dynamisch zugelinkt wurde ...

Naja, kritik ueber den Artikel wird in der naechsten C't sicher ned lange auf sich warten lassen.

Ciao ...

HumeSikkins

BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?

Soll das ein Witz sein. Ich kann mir kaum vorstellen, dass irgendjemand der auch nur ein Gramm Ahnung hat, diesen Artikel ernst nehmen kann. Ich habe beim Lesen gedacht, dass sei ein vorgezogener Aprilscherz.

1. Warum sind die Typen auf Delphi.Net gespannt, vergessen aber C++.Net zu testen (managedC++). Damit hätten sie wenigstens mal eine Aussage treffen können. Damit würde man wenigstens wissen, welchen Einfluss das .NET-Framework hat.
2. Warum verwenden die Typen die MFC statt der Standardbibliothek? Und warum dann noch diesen schwachsinnigen CObArray-Container?
3. Warum erbt SingleEntry und ListEntry von CObject? Warum verwenden sie überhaupt Vererbung, wenn SingleEntry nachher mit einem bool-Flag endet, das true liefert, falls es sich um eine Liste handelt?
4. Warum enthält der Originalquelltext unzählige Syntaxfehler, so dass er sich nicht mal übersetzen lässt.
5. Warum faseln die Typen irgendwas von "kompliziertes C++ Objektmodell", wenn sie offensichtlich keinen blassen Schimmer davon haben (a) es gibt kein standardisiertes C++ Objektmodell, b) die Komplexität hängt von der Situation ab, c) bei einfacher Vererbung ist es super simpel, d) die Typen sollten wenigstens mal "Inside the C++ Object Model" lesen)
6. Warum suchen die Typen nicht nach dem wirklichen Problem statt von dem "komplizierten C++ Objektmodell" zu faseln, von dem sie, wie in 5. bereits erwähnt, offensichtlich keinen blassen Schimmer haben.
7. Warum legen sie COBArray auf dem Heap an? (das macht drei new-Aufrufe pro add)
8. Warum übergeben sie ihre String-Objekte by value?
9. Warum verwenden sie CString, obwohl die Standardisierung von C++ nun seit mittlerweile 5 Jahren abgeschlossen ist und die Standardlib eine Stringklasse anbietet?
10. Warum liefert mein 800Mhz Athlon nach kleinen Code-Korrekturen mit den Standardeinstellungen des VC 6 Ergebnisse die näher am 2Ghz Pentium als am 1Ghz Athlon liegen?
10. Warum haben die so unglaubliche Destruktionszeiten, während ich hier ohne wilde Optimierungen auf 0.2Sek komme?
11. Warum verwenden die so einen seltsamen Algorithmus? Wo sich dieses Problem doch viel besser durch einen sorgsamen Algo statt einer anderen Sprache optimieren lässt?
12. Warum sagen die kein Wort über Dinge wie Programmgröße oder Prozessgröße?

Ich glaube ich könnte hier noch stunden weiter schreiben. Das führt aber wohl zu nichts.

Mein Fazit zu diesem Artikel:
Wer kann sollte drüber lachen. Alle anderen sollten ihn ignorieren.

Sgt. Nukem

Gregor schrieb:

Sgt. Nukem schrieb:

Bist Du Dir sicher daß die 100% (!!) Java sind?!?!

Wenn man davon absieht, dass einige dieser Spiele Bibliotheken nutzen, mit denen man OpenGL oder Direct3D von Java aus nutzen kann (LWJGL, JOGL, Gl4Java, Java3D,...), dann sind diese Spiele nach meinen Informationen zu 100% aus Java.

Naja, ist Definitionssache, ob das 100% Java ist. Nach Sun kann ein Programm, welches Java3D nutzt durchaus als 100% Java gelten. Andere sehen das enger.

Nee, dann ist's okay, dann ist's für mich auch 100% Java...

Solang die da nix mit JNI oder so zusammenfuchteln (wie ich)...

Gregor

HumeSikkins schrieb:

BTW: Was sagt ihr eigentlich zum aktuellen Benchmark von C#, C++, Java und Delphi in c't 21/2003 S.222? Da sieht C++ ja eigentlich garnicht so gut aus. Hat sich schon jemand die Mühe gemacht, sich den Quellcode der C++-Programme anzugucken und zu analysieren, welche "Performance-Fehler" gemacht wurden? ...oder wurden keine gemacht und C++ ist tatsächlich so unperformant?

Soll das ein Witz sein.

Ja, hast du den Smilie nicht gesehen?! Mir ist schon klar, dass der Benchmark nicht ernstgenommen werden kann. Die Autoren haben weder Ahnung von C++ noch von Java, sondern kommen aus der .NET- und Delphi-Ecke. Die wollten wohl ihre Sprachen einmal sehr gut darstellen.

Wenn der Benchmark überhaupt etwas zeigt, dann das, dass es in erster Linie vom Programmierer abhängt, wieviel Performance bei diesen Sprachen rausgeholt wird.

Helium

Mein Fazit zu diesem Artikel:
Wer kann sollte drüber lachen. Alle anderen sollten ihn ignorieren.

Also mir fällt eher ein oder ein ein, als ein :D.

Ich fand aber schon immer, dass die c't in Sachen Software nicht sonderlich umwerfend ist, aber wenn es um Hardware geht ist sie IMHO unschlagbar.

PS: @HumeSikkins: Darf man deine Code-veränderungen mal sehen?

HumeSikkins

PS: @HumeSikkins: Darf man deine Code-veränderungen mal sehen?

Nach dem ich an dem Versuch die Java-Version zum Laufen zu bringen gescheitert bin, habe ich das komplette Verzeichnis wieder gelöscht.

Viel verändert habe ich nicht.
Hauptsächlich Syntaxfehler korrigiert.
Die meisten Sachen habe ich noch im Kopf:

1. Ändere Syntaxfehler im Originalquellcode (Die definieren da dauernd Methoden von BSingleEntry und BListEntry. Das sollte aber CSingleEntry und CListEntry heißen. Ersetze im CListEntry-Ctor TList durch CListEntry.
Streiche das nach Änderung 4 ersatzlos.
Streiche letztes delete im Destruktor von CListEntry. Die Liste ist schließlich ein Stack-Objekt und kann deshalb nicht mit delete gelöscht werden).

2. Ändere alle const CString Parameter in const CString&
Alternativ: Ersetze CString durch std::string

3. Streiche CObject-Basisklasse von CSingleEntry und CListEntry

4. Ersetze CObArray durch vector<CSingleEntry*>

5. Korrige die build-List-Methode entsprechend.

Ich habe dann noch irgendwas in den Konstruktoren verändert, weiß aber nicht mehr genau was. Außerdem habe ich spassighalber mal die virtuellen Dtoren entfernt und stattdessen gecastet. Hat beides aber keinen signifikanten Geschwindigkeitsunterschied gebracht.

Die Zeiten habe ich hier aber noch:
1. Gesamtlaufzeit: 10.75 - 11.3 (by value Übergabe)
2. Konstruktion(?): 4.50 - 4.69
3. Destruktion: 0.2 (vector + iterator-Schleife) - 0.9 (CObArray +
Zählschleife + CObject-Basisklasse)
4. Suche(?): 5.7 - 5.9

System: Win98 SE, Athlon TB 800Mhz, 256MB RAM (60% frei), VC 6.0 EE, Release-Modus.

Real_PsychoDAD

Hi,

interessante Diskussion !

Was sagt den dieser Mikrobenchmark aber trotzdem aus ? Ich benutze recht oft for-Schleifen, wie macht man es denn besser ? Ausserdem ist dieses Programm so minimal, da kann man doch nichts mehr optimieren. Und dann schneidet da C++ noch schlechter ab, das überrascht mich und ein so überraschendes Ergebnis muss doch auch was aussagen.

Ansonsten wurde irgendwo am Anfang der Diskussion folgendes gesagt

Ok, ich habe jetzt nach längerem Suchen eine Seite gefunden, auf der ein Beta-Tester von IL-2 deine Aussage bestätigt. IL-2 nutzt Java, aber der Java-Anteil scheint nicht so groß zu sein, wie die 90%, die auf einigen Seiten behauptet werden. Ich nehme es aus der Liste. Geringe Java-Anteile sind übrigens auch in Spielen wie Vampire oder Star Wars Galaxies vorhanden.

Was heisst "zu geringen Teilen" ? Weniger als 10% ? Was macht das für einen Sinn, also man könnte z.B. die Engine in C++ proggen und dann per JNI ansprechen, aber dann würde ich nicht mehr von "geringen Teilen" sprechen.

Wo macht es Sinn ein Spiel in geringen Anteilen in Java zu entwickeln ?

Und Vampire hatte ich mal auf meinem Rechner und soweit ich weiss brauchte ich keine JRE dafür, wie ist das zu erklären ?

Gregor

Real_PsychoDAD schrieb:

Wo macht es Sinn ein Spiel in geringen Anteilen in Java zu entwickeln ?

Und Vampire hatte ich mal auf meinem Rechner und soweit ich weiss brauchte ich keine JRE dafür, wie ist das zu erklären ?

Vampire hat Java zum Beispiel für das Skripting benutzt. Das wäre zum Beispiel etwas, was ich als "geringen Teil" bezeichnen würde. Spiele, die u.a. Java nutzen, werden normalerweise ihre eigene Laufzeitumgebung mitbringen oder es wird ein native-Compiler genutzt werden, so dass keine Laufzeitumgebung benötigt wird.

das überrascht mich und ein so überraschendes Ergebnis muss doch auch was aussagen.

Ja, da du ja schon gesehen hast, dass HumeSikkins Verbesserungsvorschläge hat, wodurch die C++-Version deutlich schneller laufen würde, sollte die Aussage für dich sein, dass Benchmark-Ergebnisse mit Vorsicht zu genießen sind. Egal, wie sie aussehen. Man sollte immer beachten, wer den Benchmark gemacht hat, wer den Benchmark finanziert hat, in welchem Zusammenhang der Benchmark veröffentlicht wurde etc.! Wenn sich jemand mit mehreren Sprachen auskennt, dann kann er allein schon durch die Wahl des Benchmark-Themas bestimmen, welche Sprache vorne liegt, weil einfach jede Sprache (und jeder Compiler) Schwachstellen hat.

Nun, ich will den Autoren des c't-Benchmarks nicht unterstellen, dass sie mit Absicht die anderen Sprachen haben schlecht aussehen lassen. Viel wahrscheinlicher finde ich, dass die Autoren von C++ (und auch Java) nicht so sehr viel Ahnung haben und deshalb unfähig sind, in der jeweiligen Sprache den performantesten Code zu schreiben. C++ schneidet wohl deshalb so schlecht ab, weil es so viele Ausdrucksmöglichkeiten bietet, dass man auch sehr viele Möglichkeiten hat, sich schlecht auszudrücken. Die Autoren wollten ihr Programm wohl 1:1 portieren, haben aber nicht bedacht, dass sich C++ doch recht deutlich von C# und Java unterscheidet. Das ist ein sehr gutes Beispiel dafür, dass man nicht versuchen sollte, die Denkweise, die man in einer Sprache hat, auf eine andere zu übertragen. Das nicht ganz so schlechte Abschneiden von Java ist nur dadurch zu erklären, dass sich C# und Java eben nicht so sehr unterscheiden.

Marc++us

HumeSikkins schrieb:

1. Warum sind die Typen auf Delphi.Net gespannt, vergessen aber C++.Net zu testen (managedC++). Damit hätten sie wenigstens mal eine Aussage treffen können. Damit würde man wenigstens wissen, welchen Einfluss das .NET-Framework hat.
2. Warum verwenden die Typen die MFC statt der Standardbibliothek? Und warum dann noch diesen schwachsinnigen CObArray-Container?
3. Warum erbt SingleEntry und ListEntry von CObject? Warum verwenden sie überhaupt Vererbung, wenn SingleEntry nachher mit einem bool-Flag endet, das true liefert, falls es sich um eine Liste handelt?
4. Warum enthält der Originalquelltext unzählige Syntaxfehler, so dass er sich nicht mal übersetzen lässt.
5. Warum faseln die Typen irgendwas von "kompliziertes C++ Objektmodell", wenn sie offensichtlich
keinen blassen Schimmer davon haben (a) es gibt kein standardisiertes C++ Objektmodell, b) die Komplexität hängt von der Situation ab, c) bei einfacher Vererbung ist es super simpel, d) die Typen sollten wenigstens mal "Inside the C++ Object Model" lesen)
...

Mein Fazit zu diesem Artikel:
Wer kann sollte drüber lachen. Alle anderen sollten ihn ignorieren.

Schreib einen Leserbrief [bzw. bau eine Vorlage] und wir schicken den via C++.de hin!

Mußt nur warten bis ich wieder da bin, aber den bekommen wir schon in die Zeitschrift.

TheBigW

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

Gregor

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.

rüdiger

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.

Gregor

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.

rüdiger

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

AndreasW

sehe ich auch so.
Optimieren war nicht Ziel des Vergleiches. Siehe anderen Thread

Gregor

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.

rüdiger

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.