Yahoo Clever wird am 4. Mai 2021 (Eastern Time, Zeitzone US-Ostküste) eingestellt. Ab dem 20. April 2021 (Eastern Time) ist die Website von Yahoo Clever nur noch im reinen Lesemodus verfügbar. Andere Yahoo Produkte oder Dienste oder Ihr Yahoo Account sind von diesen Änderungen nicht betroffen. Auf dieser Hilfeseite finden Sie weitere Informationen zur Einstellung von Yahoo Clever und dazu, wie Sie Ihre Daten herunterladen.
Benutzt C++ den Coprozessor?
Ich habe eine 3D-Engine in VB08 geschrieben. Jetzt möchte ich Teile nach C++ portieren, weil VB bei 5000 Teiltransparenten Polygonen mit AntiAliasing "nur noch" 8fps schafft. Doch wenn C++ den Coprozessor für Mathematische Operationen nicht nutzt, wird es eher langsamer.
Ich möchte sowieso nur die Teile auslagern, die Berechnungen durchführen. Die Polygone müssen mit einer .NET-basierten Sprache geschrieben werden, weil GDI+ die zur Zeit wohl schnellste Möglichkeit für umfangreiche Graphikausgaben (Gepuffert, Transparent, AntiAliasing) ist. Da GDI+ sowieso in C geschrieben ist, dürfte das kein Problem darstellen. VB ist aber Coprozessorgestützt, so dass umfangreiche Berechnungen (Drehungen, Transformationen) vielleicht in C++ nicht schneller wären. Es geht mir darum, den GPU aus dem Spiel zu lassen, um eine unabhängige Plattform zu schaffen. Ich habe das alles achon in VB geschrieben, so dass ich es nur noch nach C++ portieren muss. Außerdem habe ich mir gedacht, dass ich das Programm wie folgt für Quadcore-Prozessoren mit Coprozessor optimiere:
Core1: Windows+Programme
Core2: Transformationen, Rotationen->CoCPU
Core3: 3D-Modell-Berechnung-CoCPU
Core4: Darstellung->GDI+
Rest siehe nächste Details
Die Threads würden sich in VB weit effizienter gestalten lassen, da ansonsten alle paar ms tausende von Polygonen nach C++ und zurück übergeben werden müssten. Das ist nicht besonders schnell und verursacht overhead und 2-3 mal so viel Ram-Verbrauch. Das bedeutet (ohne Overhead) bei 10000 Polygonen und 20fps und 3 Threads mit hin und Rückübergabe 220MB Netto, wobei noch ca 20% overhead und der Normale Verbrauch verbleibt. Außerdem der Verbrauch der Quelle, die die Rohdaten produziert. Macht so 300-500MB (Mit Cache für Threadsyncronisation gut 600-700MB), was schon ausreicht, um ein gutes System zum Absturz zu bringen. Nur in VB würde ein drittel, also 250MB genügen.
3 Antworten
- Anonymvor 1 JahrzehntBeste Antwort
Ähm, wieso sollte ein in C++ geschriebenes Programm eher langsamer laufen als ein unter VB erstelltes? Die heutigen C++ Compiler erzeugen so guten Maschinencode, der kann fast schon mit purer Assemblerprogrammierung mithalten und sollte um Längen schneller laufen als ein unter VB erstelltes Programm.
Zur Frage mit dem mathematischen Coprozessor:
Der sollte automatisch von jedem Programm bei mathematischen Operationen genutzt werden, das steuert die CPU selbst. Da spielt die Programmiersprache keine wesentliche Rolle (einen guten Compiler vorausgesetzt).
Was es allerdings seit einiger Zeit gibt ist die Nutzung der GPU (also der Prozessor der Grafikkarte), die bestimmte Berechnungen um ein Vielfaches schneller erledigt als jede normale CPU. Dazu musst Du aber eine bestimmte Library einbinden (abhängig von der GPU) und sehr wahrscheinlich einige spezielle Funktionen dieser Library in Deinem Programm aufrufen. Das wird es eher unter C++/C# als unter VB geben und setzt auch voraus, dass Du eine leistungsfähige Grafikkarte im Einsatz hast.
Nachtrag:
Was meinst Du mit "VB ist aber Coprozessorgestützt"? Wie tquadrat_org dargelegt hat, jede Programmiersprache nutzt automatisch den in der CPU integrierten mathematischen Coprozessor, wenn der Compiler kein absoluter Schrott ist.
Eine Aufteilung in 2 verschiedene Programmiersprachen (falls ich Dich richtig verstanden habe) macht m.E. keinen Sinn, weil dann die Threadsteuerung tatsächlich mehr Overhead produziert als man Gewinn durch die Auslagerung hätte. Wenn Du 4 Kerne auslasten möchtest, dann wird es ohnehin nicht trivial. Abhängig davon was Du vorhast, würde ich möglichst viele Prozesse starten und die Zwischenergebnisse sammeln, um sie final auszuwerten und zusammenzuführen. Ob sich das realisieren lässt kannst nur Du beantworten.
- vor 1 Jahrzehnt
@The Coder: Müll kann man in jeder Programmiersprache programmieren; also kann man problemlos auch in C++ ein Programm schreiben, das in VB viel schneller abläuft. Und da Du es schon erwähnt hast: das hängt natürlich auch von der Qualität des Compilers ab.
Die von VB in den aktuellen Versionen verwendeten Bibliotheken verwendet automatisch jene Prozessoroperationen, die früher nur in den mathematischen Co-Prozessoren zur Verfügung gestellt wurden. Das gilt auch für Programme, die mit aktuellen C++-Compilern übersetzt wurden. Während man aber bei VB keine Möglichkeit hat, hier etwas einzustellen, kann man bei C++ über die Compiler-Switches hier einige Verheerung anrichten. Per default nehmen die MS Compiler aber immer den aktuellen Prozessor als Ablauf-Umgebung an. Wenn Du also nicht von irgendwoher einen Uralt-486 ausgegraben und auch nicht an den Switches herumgespielt hast, dann wird Dein Code mit den OpCodes für den Co-Prozessor übersetzt.
Aber Dir ist schon bekannt, dass schon seit geraumer Zeit die ***87 Co-Prozessoren in den eigentlichen ***86 CPU Chip integriert sind?
