Seit wann ist VB schneller als C++?

[Knuddlbaer]

Oder weil vllt. die "Workarounds" um auf unterster Ebene anzugelangen zu langsam sind ?

Zum CT Artikel ein Zitat Beitrag 66 aus Lohnt es sich noch C++ zu lernen?

Zitat:

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.

und noch ein Zitat Beitrag 70 aus
Lohnt es sich noch C++ zu lernen?

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.

Für den genauen Zusammengang der Zeiten empfielt es sich das gesammte Topic zu lesen.

[Unix-Tom]

Und ich sag es immer wieder!
Womit wurden den die NET-Sprachen geschrieben ?
Etwa mit C#! Sicherlich nicht.

[rapso]

das mono projeckt kann mit ihrem eigenem c# compilier angäblich das ganze .NET zeug sammt compilier selbst compilieren.

sorree dass ich dir in den rücken fall

rapso->greets();

[Akzepto]

Akzeptiert doch entlich das C schwer zu lernen ist, kompliziert in der Anwendung und sein Geschwindigkeitsvorteil schon lange verloren hat.

[Jester]

Zu dem c't Artikel, die bauen da auch irgendwo massenweise strings zusammen:

immer mit str = str + neuesteil;
Wenn man das noch in
str += neuesteil; ändert erhält man auch nochmal einen ordentlichen Performance-Schub.

Weiß jemand, ob's die neuen Source bei heise gibt?

[Akzepto]

Jester schrieb:

... in str += neuesteil; ändert erhält man auch nochmal einen ordentlichen Performance-Schub.

Aha, das ist also der Grund warum C langsamer ist. Sehr interessant.

Sucht doch nicht nach Ausreden.

Ausserdem wird dieser Teil vom Compiler optimiert.

[rapso]

http://www.heise.de/ct/ftp/03/21/222/

das einfachste ist erstmal alle const CString in const CString& replacen, das was jeder c++ anfänger lernt, das muss man die IDE dort noch per replace machen lassen. das bringt bei mir das ding von ~16 auf 9.5 sekunden.

wenn man dann von CString auf std::string mit der stlport ported, wird das sicherlich schon extrem performance bringen.

rapso->greets();

[rapso]

Akzepto schrieb:

Jester schrieb:

... in str += neuesteil; ändert erhält man auch nochmal einen ordentlichen Performance-Schub.

Aha, das ist also der Grund warum C langsamer ist. Sehr interessant.

Sucht doch nicht nach Ausreden.

Ausserdem wird dieser Teil vom Compiler optimiert.

das problem ist, dass man mit c++ alles machen kann was mit java,c#,vb möglich ist, außerdem kann man noch weitere optimierungen einbringen. es ist also rein logisch nicht möglich dass die sprachen schneller sind als c++.
c++ setzt aber voraus dass man es in jedem codeabschnitt perfeckt einsetzt damit es aus optimal läuft, wohingegen java,c#,vb generische lösungen haben die für anfänger sehr viel arbeit abnehmen und er nichtmal wissen muss ob ein string kopiert wird oder nur eine referenz übergeben wird, man muss meißt nichtmal den speicher managen was bei optimaler programmierung ein c++ programm selbst macht (siehe whitepaper von AMD und INTEL)

hier kannst du mal durchlesen wie freaky man sein muss, um das letzte an performance rauszuhollen, das ist in java,c#,vb niemals möglich, weshalb dort nur die gleiche performance wie in c++ zu hollen ist, wenn jemand für den prozessor spezialisierten code in den compiler einbaut...dann wohl in c++ oder delphi oder in welcher hardware naher sprache auch immer...

http://www.flipcode.com/tutorials/tut_fastmath.shtml

rapso->greets();

[Akzepto]

Werden wir je diese Stufe der C/C++ Programmierung erreichen?

Für mich sind C/C++ Programmierer Leute die ständig auf der Suche nach dem optimalen Code sind.

[rapso]

Akzepto schrieb:

Werden wir je diese Stufe der C/C++ Programmierung erreichen?

Für mich sind C/C++ Programmierer Leute die ständig auf der Suche nach dem optimalen Code sind.

genau das ist es ;), nun hast du es verstanden *hehe*

das ist auch der grund weshalb du in java für jeden "mißt" eine funktion hat, wie "Optimiser" letztens hier rausfand. sogar um zu prüfen ob eine gerade mit einem box kollidiert gibt es in java ne funktion. wenn man das selbst implementiert in c++ (einfach frei hand), ist man deswegen wohl langsammer, wenn man sich in c++ richtig mühe gibt, kann man für seine speziellen fälle vielleicht schneller sein als die java implementierung, aber sobald man in java etwas machen möchte, wofür es keine lib gibt, dann wird es ziemlich langsam.

so z.b. kopieren eine speicherausschnittes

java vielleicht

for(int a=0;a<Array1.Lenght();a++)
Array2[a]=Array1[a];

in c++ vielleicht

for(int a=0;a<sizeof(Array1)/2;a++)
*reinterpret_cast<double*>(Array1)[a]=*reinterpret_cast<double>(Array2*)[a];

schon hat man die hälfte der schleifendurchläufe und vielleicht die 5% mehr pefromance die c++ eben erlaubt und andere sprachen vielleicht nicht.

natürlich könnte man in java dann eine lib zum kopieren haben und in c++ das memcpy benutzen. man könnte in c++ aber auch die mmx funktionen mit memory prefetching nutzen und schon ist man wieder fixer als java. dann könnte man das mit DMA transfer auf gewissen systemen mit c++ lösen (z.b. playstation oder gameboy) und in java muss man hoffen dass die lib das von selbst macht.. wobei man das eventuell garnicht möchte und die lib dann extra funktionen bräuchte "memcpyDMA" und "memcpy" für java, wenn man glück hat. in C++ baut man sich die eben mal selbst ein und hat das optimum das man haben möchte.

c++:
erlaubt für alles optimum, man muss es aber oft selbst richtig anstellen

java:
hat für vieles optimale libs (die dann eigentlich grundsätzlich mit c++ mithalten), wenn es etwas ausgefallenes ist, dann muss man es selbst erstellen und ist dann oft viel langsammer als c++ (wegen weniger erfahrung mit optimierung und dem allgemeinem code von java gegenüber für dem für eine cpu optimierten code von c++)

rapso->greets();

[Gregor]

rapso schrieb:

so z.b. kopieren eine speicherausschnittes

Tut mir leid, auch dafür gibt es eine entsprechende Methode in Java: System.arraycopy

[Gregor]

rapso schrieb:

das problem ist, dass man mit c++ alles machen kann was mit java,c#,vb möglich ist, außerdem kann man noch weitere optimierungen einbringen. es ist also rein logisch nicht möglich dass die sprachen schneller sind als c++.

Das Problem ist, dass du nur dann alles in C++ machen kannst, was Java machen kann, wenn du Java nachprogrammierst. Kann C++ von Haus aus Inlining bei vorliegender Laufzeitpolymorphie machen? Nein, denn dafür braucht man eine virtuelle Maschine. Das kannst du erst, wenn du dir eine virtuelle Maschine in C++ programmiert hast. Alles, was Java kann, kannst du entsprechend erst, wenn du Java komplett nachprogrammiert hast.

[rapso]

Gregor schrieb:

rapso schrieb:

so z.b. kopieren eine speicherausschnittes

Tut mir leid, auch dafür gibt es eine entsprechende Methode in Java: System.arraycopy

das hab ich auch geschrieben im anschluss, das hier war, wie es da auch steht, nur ein beispiel.

rapso->greets();

[rapso]

Gregor schrieb:

rapso schrieb:

das problem ist, dass man mit c++ alles machen kann was mit java,c#,vb möglich ist, außerdem kann man noch weitere optimierungen einbringen. es ist also rein logisch nicht möglich dass die sprachen schneller sind als c++.

Das Problem ist, dass du nur dann alles in C++ machen kannst, was Java machen kann, wenn du Java nachprogrammierst. Kann C++ von Haus aus Inlining bei vorliegender Laufzeitpolymorphie machen? Nein, denn dafür braucht man eine virtuelle Maschine. Das kannst du erst, wenn du dir eine virtuelle Maschine in C++ programmiert hast. Alles, was Java kann, kannst du entsprechend erst, wenn du Java komplett nachprogrammiert hast.

klar geht das, schonmal von selfmodifing code gehört? an der stelle wo du eine optimierung möchtest machst du einen jump zu einer funktion die die daten analysiert und dann den entsprechenden code anstelle des jumps einbindet.

außerdem, inlining macht die cpu, dafür gibt es extra seit dem pentium-class eine laufzeitoptimierung (bzw. eigentlich macht das der K5 als erste cpu), der Itanium compiler gibt dabei der cpu sogar eine hilfestellung, der itanium besteht aus doppelt sovielen einheiten wie nötig und arbeitet parallel immer zwei mögliche wege, wenn ein conditionaljump eintritt wird dann der richtige weitergerechnet.
zu dem gibt es für c++ profiler die das programm zur laufzeit analysieren und im nachinein nochmal umkopilieren damit es für die zu erwartenden daten optimal läuft, dabei kannst du der cpu mit der richtigen condition beim bedingten spung auch selbst genau angeben was erwartet wird (also ob der sprung stattfindet oder nicht).

ich bezweifle mal dass java "selfmodifing code" erlaubt oder garantieren kann dass es eine condition so stellt, dass es auf dem gerade laufendem prozessor mit der jumpprediction richtig interagiert.

rapso->greets();

ps. es gibt virtuellmaschines und garbage collectors für c++, also egal welches argument du bringst, du könntest diese spezialfälle _auch_ mit c++ lösen.

[Knuddlbaer]

Die Diskusionen führen nicht weiter.

Jede Sprache ist für einen Speziellen Anwendungsfall entwickelt worden.
Die "beste" Sprache gibt es einfach nicht. Diskusionen dieser Art gab es massig im Forum.

Leute die wirklich C++ Programmieren werden es ähnlich sehen das jede sprache ihren Einsatzbereich hat. Geschwindigkeit ist nicht alles im leben. Zeit kostet Geld. Und meistens ist die Entwicklungszeit teurer als die Laufzeit des Programmes.

Was ich aber ätzend finde sind Leute die Argumentieren das C schlecht und schwer zu erlernen ist. Wenn C zum Vergleich herangezogen wird dann bitte die zu vergleichenden Sprachen aus dem passenden Jahr vergleichen.

Wo war denn Java mitte 1990 ?

Wir vergleichen also das neueste Java Hight Tech mit alter schmiedekunst.

Das es C++ gibt sollte sich eigentlich rumgesprochen haben. Dadurch wird die Ausführung der Programme nicht unbedingt generell schneller, aber es ist wesentlich einfacher zu erlernen und anzuwenden.

Wer sich an Diskusionen C++ vs XX laben will kann ja mal die Suchmaschiene benutzen die das Forum bietet. Da gibts massig stoff zu.

[Jester]

Akzepto schrieb:

Jester schrieb:

... in str += neuesteil; ändert erhält man auch nochmal einen ordentlichen Performance-Schub.

Aha, das ist also der Grund warum C langsamer ist. Sehr interessant.

Sucht doch nicht nach Ausreden.

Ausserdem wird dieser Teil vom Compiler optimiert.

Nein, wird er nicht, darf der Compiler nicht. Der Copy-Ctor-Aufruf ist garantiert. Ein temporäres Objekt anlegen, das dann kopieren... kostet halt mehr. Wenn Du's ned glaubst probier's aus!

[rapso]

Jester schrieb:

Akzepto schrieb:

Jester schrieb:

... in str += neuesteil; ändert erhält man auch nochmal einen ordentlichen Performance-Schub.

Aha, das ist also der Grund warum C langsamer ist. Sehr interessant.

Sucht doch nicht nach Ausreden.

Ausserdem wird dieser Teil vom Compiler optimiert.

Nein, wird er nicht, darf der Compiler nicht. Der Copy-Ctor-Aufruf ist garantiert. Ein temporäres Objekt anlegen, das dann kopieren... kostet halt mehr. Wenn Du's ned glaubst probier's aus!

[ergaenz]
darf er optimieren wenn seine logic rausfindet dass dadurch kein logischer unterschied entsteht.. könnte sogar sein, dass er alles inlined und dann unnötiges kopieren von variablen auflöst.

aber einfach so grundsätzlich aus a=a+1; a+=1; oder a++; darf er wohl nicht.[/ergaenz]

rapso->greets();

[Helium]

das problem ist, dass man mit c++ alles machen kann was mit java,c#,vb möglich ist, außerdem kann man noch weitere optimierungen einbringen. es ist also rein logisch nicht möglich dass die sprachen schneller sind als c++.

Gewagte Aussage. Ich schreib dir mal ein kleines Javaprogramm, das extrem auf Javas Reflexionsfähigkeiten beruht und du bastelst mir dann das entsprechende C++-Programm. Ich wünsche schonmal viel spaß.

Vielleicht sollte doch lieber Gregor doer sonstwer das Programm schreiben, da meine Javakentnisse recht mieß sind.

[rapso]

Helium schrieb:

das problem ist, dass man mit c++ alles machen kann was mit java,c#,vb möglich ist, außerdem kann man noch weitere optimierungen einbringen. es ist also rein logisch nicht möglich dass die sprachen schneller sind als c++.

Gewagte Aussage. Ich schreib dir mal ein kleines Javaprogramm, das extrem auf Javas Reflexionsfähigkeiten beruht und du bastelst mir dann das entsprechende C++-Programm. Ich wünsche schonmal viel spaß.

Vielleicht sollte doch lieber Gregor doer sonstwer das Programm schreiben, da meine Javakentnisse recht mieß sind.

ich hab nicht gesagt, dass es einfacher ist oder dass es schlau wäre alle sachen mit c++ zu machen, aber zu behaupten java wäre schneller ist leider absurt.

von mir aus können wir was einfaches machen, ein programm das ein einziges dreieck zeichnet oder sonst was, wobei man nicht ne fertige lib nutzt und die performance vergleichen.

am ende wirst du auch drauf kommen, dass assembler das schnellste sein muss, weil alles darauf basiert... trotzdem codet man nicht sonderlich viel damit. die meißten programme von heute sind garnicht auf performance getrimmt, sondern darauf mit generischen lösungen die vorgabe zu erreichen. insofern ist c++, java, c# ... gleich gut um seine arbeit zu erfüllen. java hat ein paar mehr libs die viele sachen optimal erledigen (wenn man für sein tun die gerade nötigen funktionen kennt) und c++ hat atomarere lösungen die erlauben für performance sehr hardwarenah zu coden.

ich weiß nicht was das eigentlich immer soll, wozu wollen andere sprachen schneller sein als die sprachen mit denen sie eventuell erstellt wurden? das ist rein logisch nicht möglich. wozu? früher wurde auch oft behauptet dass c schneller als assembler sei und c++ schneller als c (darauf versteifen sich heute immer noch leute) und nun java/c# vs. c++

rapso->greets();

[Gregor]

rapso schrieb:

ich weiß nicht was das eigentlich immer soll, wozu wollen andere sprachen schneller sein als die sprachen mit denen sie eventuell erstellt wurden? das ist rein logisch nicht möglich. wozu? früher wurde auch oft behauptet dass c schneller als assembler sei und c++ schneller als c (darauf versteifen sich heute immer noch leute) und nun java/c# vs. c++

1. Ich kann dir sagen, was das bei Java soll:

Java hat nunmal ein "Ist lahm"-Image, was früher auch sehr berechtigt war. Da es dieses Image einfach nicht los wird, weise ich zumindest öfter mal darauf hin, dass Java garnicht so lahm ist. Es geht mir da aber nicht darum, Java schneller als C++ darzustellen, es geht mir nur darum, darauf hinzuweisen, dass die Sprachen mitlerweile so ziemlich in der gleichen Liga spielen, was die Geschwindigkeit entsprechender Programme betrifft.

2. Deine Assembler-ist-am-Schnellsten Argumentation hat eine Schwachstelle. Diese Schwachstelle ist der Mensch. Bei Assembler kannst du zwar sagen, dass es nur am Programmierer liegt, der ja eigentlich perfekt sein könnte, wenn du mit dem gleichen Argument aber aussagen möchtest, dass C++ immer schneller als Java sein kann, dann ist das falsch. Bei C++ liegt es nicht nur am Programmierer des jeweiligen Programms, sondern auch am Compiler bzw. am Programmierer des Compilers. Ich bin mir ziemlich sicher, dass alle Compiler, die es so gibt, sehr suboptimal sind. Zudem ist es bei C++ schwieriger, gute Compiler zu schreiben, als bei Java, da die Sprache deutlich komplexer ist. Ok, C/C++ gibt es schon länger, entsprechend hatten die Menschen mehr Zeit, die Compiler zu optimieren, mit anderen Worten heißt das aber, dass bei Java noch mehr rauszuholen ist, als bei C++.