Seit wann ist VB schneller als C++?

Knuddlbaer

Ich denke also das man nicht die geschwindigkeit einer Sprache anhand der Ansteuerung einer API messen kann. (@VBJAVAMAN)

Die Frage wieso VB eine höhere Framerate nach sich zieht wird denke ich erst nach Untersuchung der Quelltexte möglich sein.

SirLant

Es ist wohl definitiv kein Problem in C++ oder C Quellcode zu schreiben, der
verdammt langsam ist, jdm der gut VB kann und die feinheiten zum optimieren
(soll auch Leute geben, die mit VB arbeiten und trotzdem Ahnung haben) kennt,
der kann sicher da was rausholen und im günstigen Fall schneller als schlechter
C/C++-Code sein.

Alles nur ausreden. In unserer heutigen Zeit ist es irrelevant mit welcher Srpache man entwickelt. VB ist auch kein Interpreter mehr. Und alles auf den "dummen" C Programmierer zu schieben ist zu einfache. Oder meint ihr ihr seit die über Gurus? (ausser TGGC )

Gregor

ingaux schrieb:

Haben die in der ct dazu schon mal was gesagt, zu dem versauten Test?

Ja, und zwar in c't 23/2003 auf Seite 232. Die haben die Programme nochmal etwas optimiert. Kurz zusammengefaßt:

C# :     neue Version : 3,7s  --- alte Version :  6,3s
Java :   neue Version : 3,7s  --- alte Version :  8,8s.
Delphi : neue Version : 4,25s --- alte Version :  7,5s
C++ :    neue Version : 4,5s  --- alte Version : 12,3s

In dem Artikel stehen die Optimierungen drin. Es wäre ganz interessant, wenn sich das hier jemand angucken könnte und sagen könnte, was alles noch hätte gemacht werden müssen. Schließlich ist C++ immernoch Schlusslicht.

Sag ich doch. Wer denk C sei die schnellste Sprache nach Assembler, der hat keine Ahnung. Ich sage es schon immer. Die Zeiten sind vorbei. Das war ein mal. Heute gibt es keinen Unterschied mehr.

Die ganzen Libs und API's die man einbinden muss bremsen die Sprache. Aber wer will schon eine Anwendung ohne STL und Co erstellen? Ich nicht. Seit flexibel. Nutzt die Vorteile aller vorhandenen Sprachen.

Entwickle ich eine Steuersoftware für einen Turboladerteststand erstelle ich die Benutzerobefläche mit C# oder VB. Den Teil der die Messensoren steuert mach ich mit C.

<EDIT> ...micht weil C schneller ist. Sondern weil ich auf unterster Ebene arbeiten kann <EDIT>

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();

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?

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();

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.