4. Seit wann ist VB schneller als C++?

Seit wann ist VB schneller als C++?

  • ?

    hahaha 🙂

    0
  • S

    HANZO schrieb:

    Also Jungs, 500FPS der eine 200FPS der andere. Auch wenn er den C/C++ Code optimieren sollte glaube ich nicht das danach C/C++ 1500FPS schaft. Was er ja müsste. Weil er soll ja sehr viel schneller sein als VB und nicht gleich oder etwas schneller.

    PS WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN WIR WOLLEN CODE SEHEN WIR WOLLWN CODE SEHEN

    In einem Post so viele Rechtschreibfehler... 🙄

    😉 🤡

    0
  • I

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

    0
  • R
    Mod

    [quote="Sgt. Nukem"]

    HANZO schrieb:

    In einem Post so viele Rechtschreibfehler... 🙄

    😉 🤡

    da haste den falsch'n zittiert *fg*

    rapso->greets();

    0
  • ?

    Du jetzt auch 😃

    btw wir warten immer noch auf den Source 🙄

    0
  • ?

    Also, wenn jemand die Bin´s des Directx9 SDK´s startet(Demo´s und Tutorial´s), so wird er merken das in den Anwendungen die in C#, VB und C++ vorhanden sind sich immer das gleiche herausstellt! Visual Basic ist mit c++ gleich auf und c# liegt immer dahinter.

    Warum?

    0
  • K

    Wieviel hat das VB denn überhaupt damit zu tun ?
    Kann ich mir das nicht so vorstellen das die Hauptarbeit von seitens der DX Api gemacht wird ?

    0
  • ?

    Ja, das denke ich auch! Aber warum sind dann bei einigen Applikationen unterschiede von 5 - 300 Frames festzustellen?

    Gruß Frank

    0
  • ?

    frank2 schrieb:

    Also, wenn jemand die Bin´s des Directx9 SDK´s startet(Demo´s und Tutorial´s), so wird er merken das in den Anwendungen die in C#, VB und C++ vorhanden sind sich immer das gleiche herausstellt! Visual Basic ist mit c++ gleich auf und c# liegt immer dahinter.

    Warum?

    Was beweist das C/C++ keine Zukunft hat. Das war einmal das C/C++ das schnellste war (ausser asm). Leute, es sollte euch klar werden das nur das Ergebniss zählt. Und nicht mit welcher Sprache oder API dieses Ziel erreicht wurde.
    Wer C/C++ kann sollte dabei bleiben. Wer es noch lernen will sollte sich frage ob es nicht Alternativen gibt.

    0
  • H

    Wer es noch lernen will sollte sich frage ob es nicht Alternativen gibt.

    Aber welche Alternativen hat man?

    0
  • K

    Hm, so pauschal zu sagen C++ sei langsamer .. WEiß nicht.

    Und das ne Interpretersprache schneller sein soll ? WEiß nich.

    Ich denke es hat hier viel mit der Programmierung u. Compiler zu tun.
    Wie will man bitte sprachen vergleichen die überwiegend API Aufrufe verwenden ?

    Und dann die frage:

    In was ist denn das DX9 geschrieben ? VB ?

    0
  • T

    Knuddlbaer schrieb:

    Und dann die frage:

    In was ist denn das DX9 geschrieben ? VB ?

    Wenn man darüber nachdenkt was DX überhaupt macht sollte man schnell eine Antwort finden. DX bringt die möglichkeit über High Level Sprachen mit der Grafikkarte zu kommunizieren ohne Abhängig zu sein was es für eine ist. Also wird es sicherlich Assambler oder ähnliches sein. Die Matrix und Vektorrutinen sind auch in Assambler für die verschiedenen CPUs in optimierter Form.

    0
  • K

    🤡

    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.

    0
  • S

    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.

    0
  • ?

    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 🙂 )

    0
  • G

    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. 😃

    0
  • ?

    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.

    0
  • ?

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

    0
  • K

    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.

    0
  • U

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

    0
Anmelden zum Antworten