Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von »dot« (29.06.2012, 00:51)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
mov edx, [ebp+0008]
mov eax, [edx+0078]
add eax, 01
mov ecx, [ebp+0008]
mov [ecx+0078], eax
mov edx, [ebp+0008]
cmp dword ptr [edx+0078], 08
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »BlueCobold« (29.06.2012, 07:03)
Ich kann dir nur empfehlen, dich mal vorurteilsfrei und wirklich ernsthaft mit C++ zu beschäftigen, anstatt einfach irgendwelche Meinungen aus irgendwelchen Foren oder Blogs anzunehmen, ohne jemals selbst wirklich gesehen zu haben, wozu die Sprache fähig ist. In ein paar Jahren wirst du die Sache dann vermutlich anders sehen, wenn du es zulässt...
Ein paar Bücher, die ich dazu sehr empfehlen kann, wären:
The C++ Programming Language
Effective C++
Modern C++ Design
zum einen sprichst du (S. P. Gardebiter) den energieverbrauch an. auf der einen seite frisst heutige hardware weniger als noch vor 10 jahren und zum anderen würdest du den stromverbrauch auch in die höhe treiben, um ein möglichst effizientes Programm rauszubekommen. Oder optimirst du ohne pc?
zum anderen warum nutzt du nicht assembler wenn du so ein geschwindigkeitfetischist bist? soweit ich weis ist es schneller als C/c++
Es steht dir natürlich frei welche Sprache du verwendest, jede hat seine Vor und Nachteile und ist je nach Anwendung sinnvoller.
Bei zunehmend größeren Projekten hat es Vorteile sich an OO Sprachen mit großen Bibliotheken zu halten, da die Algorithmen nach mathematischen Regeln optimiert werden, soetwas bekommt man als Hobbyprogrammierer nicht hin. Zudem ist es übersichtlicher und die Optimierungstools sind mächtig. Dass irgendwelche Kleinigkeiten dabei auf Grund der Abstraktion auch mal mehr Resourcen fressen mag sein, fällt aber immer weniger ins Gewicht. Dazu hat man noch den Vorteil, dass Änderungen im Nachhinein leichter fallen.
Das Argument vom Strom sparen ist beim PC irrelevant (1/3 mehr Befehle sind unrealistisch). Das mag bei einzelnen Methoden vllt passiern aber ist sicher nicht die Regel (Virtuelle Funktionen wären ein gutes Bsp).
Der von dir erwähnte Speicherplatz für Zeiger wird zusätzlich gebraucht ja, aber nur während der Gültigkeit und vorallem ist der Speicherplatzbedarf so gering, dass man es gar nicht in Worte ausdrücken kann. (32 oder 64 bit). Vorallem ist doch Zeigerarithmetik wirklich das, was C so effizient macht (Und auch Assembler). Es werden eben keine temporären lokalen Kopien im Stack abglegt, dafür hat man eben eine große Fehleranfälligkeit, wenn man mal was verpeilt.
An den Unis, HS in Firmen überall wird gepredigt: Vermeide globale Variabeln, nutze moderne Paradigmen (OO) usw. Warum? Weil es um Zeit und Geld geht.
Du hast was bei dem Wiki Zitat weggelassen um dein Argument zu untermauern, ist aber wichtig:
Übrigends: Ich bin heute schon ein wenig genervt, falls ich etwas zu direkt ausgedrückt haben sollte im Post davor, sry. Und ich hab alles gelesen, zumindest überflogen.
ich suchte mal nach dem Artikel und dem Code von diesem C vs C++ test und angeblich soll es der hier sein: http://people.redhat.com/bkoz/benchmarks…/oopack_v1p8.cc
Ich glaube jeder kann sich jetzt ganz schnell ein Bild davon machen, warum C ach soviel besser ist (schonmal Autos verglichen wobei bei dem einen der Innenraum mit Pflastersteinen befüllt war?) .
P.S: ein Musterbeispiel (und erster Treffer bei google) für einen falschen Alarm in Sachen "compiler überflüssige instruktionen" und sehr "kluger" manueller Optimierung http://www.mikrocontroller.net/topic/251475 (Spoiler für lesefaule: Variablentyp war ungünstig gewählt).
Nie im Leben ist das von VC++ oder g++ oder gcc ausgespuckter und optimierter Code. Das ist höchstens Debug-Code ohne jedwede Optimierung. Oder da weiß jemand nicht, wie er die Flags des Compilers richtig setzen muss. Sorry, aber ich habe noch nie solchen Unfug von VC++ generiert gesehen. Es würde nämlich nichtmal die beiden Befehle
mov eax, [edx+0078]
add eax, 01
nacheinander schreiben, weil das Pipeline-Stalls verursachen würde. Sorry, aber dieses Beispiel kaufe ich Dir nicht ab.
Ja, man *kann* definitiv OOP-Varianten wesentlich langsamer schreiben, als Prozedurale. Es geht genauso aber auch andersrum. Wenn ich diese Unfugsbehauptung also beweisen *will*, dann geht das natürlich.
Gerade bei Verarbeitung tausender Daten in Matrizen brauch ich mich nicht wundern, dass eine Array-Variante mit perfektem Cache-Verhalten besser ist als eine im RAM zerhackstückte Verteilung der Daten. Das ist aber kein Problem von OOP, sondern von falscher Verwendung von OOP zum Missbrauch eines fehlerhaften Beweises. In diesem Fall gilt wohl eher "quo errat demonstrator" statt "quod erat demonstrandum".
Ich kann mich BlueCobold da nur anschließen. Ist dieser Code zufälligerweise beim Debuggen mit Visual Studio in der Disassembly-Ansicht hochgekommen? Im Debug-Build wundert der Code mich nicht. Das aber auch aus gutem Grund, mit Optimierungen kann man kaum noch vernünftig Debuggen.
zum einen sprichst du (S. P. Gardebiter) den energieverbrauch an. auf der einen seite frisst heutige hardware weniger als noch vor 10 jahren und zum anderen würdest du den stromverbrauch auch in die höhe treiben, um ein möglichst effizientes Programm rauszubekommen. Oder optimirst du ohne pc?
Dass neue Hardware weniger frisst, halte ich für ein Gerücht, mein PC hat ein 450 Watt Netzteil, ich hatte mal einen alten 133er, der hatte glaub ich ein 100 Watt Netzteil, kann auch sein, dass es 50 oder 100 mehr waren. Aufjedenfall ist das Blödsinn, alte Desktop PCs hatten einen viel geringen Verbrauch als neue. Richtig ist aber auch, dass die Technologie immer besser wird und richtig moderne PCs sich den alten auch hin und wieder mal annäheren.
Bei dieser Logik, gibt es auch ein Gegenargument, es wird wahrscheinlich wesentlich mehr Leute geben, die das Programm benutzen als die, die es entwickeln.
Außerdem ging es bei der Stromgeschichte immernoch um ein bestimmtes Zitat, nämlich um das hier: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", habe ich in diesem Thread aber auch schonmal geschrieben.
Es steht dir natürlich frei welche Sprache du verwendest, jede hat seine Vor und Nachteile und ist je nach Anwendung sinnvoller.
Bei zunehmend größeren Projekten hat es Vorteile sich an OO Sprachen mit großen Bibliotheken zu halten, da die Algorithmen nach mathematischen Regeln optimiert werden, soetwas bekommt man als Hobbyprogrammierer nicht hin. Zudem ist es übersichtlicher und die Optimierungstools sind mächtig. Dass irgendwelche Kleinigkeiten dabei auf Grund der Abstraktion auch mal mehr Resourcen fressen mag sein, fällt aber immer weniger ins Gewicht. Dazu hat man noch den Vorteil, dass Änderungen im Nachhinein leichter fallen.
Dass es bei zunehmend größeren Projekten oft Vorteile mit sich bringt, da habe ich nie in Abrede gestellt, allerdings gibt es auch für prozedurale Sprachen genug Bibliotheken die mithalten können. Soweit ich weiß ist OpenGL z.B. komplett in C geschrieben.
Das Argument vom Strom sparen ist beim PC irrelevant (1/3 mehr Befehle sind unrealistisch). Das mag bei einzelnen Methoden vllt passiern aber ist sicher nicht die Regel (Virtuelle Funktionen wären ein gutes Bsp).
nochmal, beim Strom ging es um folgendes Zitat: "Wo Leistung im Überfluss ist, kann man keine Verschwenden.", ich wiederhole mich langsam, weil ihr euch meine Postings nicht genau durchlest.
Es ging mir allgemein um Resourcenverschwendung, die de facto da ist. Wenn du mir das mit den 1/3 mehr Befehle nicht glaubst, steht es dir frei das entsprechende Programm selber zu disassemblieren und selbst zu sehen.
Ja, man *kann* definitiv OOP-Varianten wesentlich langsamer schreiben, als Prozedurale. Es geht genauso aber auch andersrum. Wenn ich diese Unfugsbehauptung also beweisen *will*, dann geht das natürlich.
Gerade bei Verarbeitung tausender Daten in Matrizen brauch ich mich nicht wundern, dass eine Array-Variante mit perfektem Cache-Verhalten besser ist als eine im RAM zerhackstückte Verteilung der Daten. Das ist aber kein Problem von OOP, sondern von falscher Verwendung von OOP zum Missbrauch eines fehlerhaften Beweises. In diesem Fall gilt wohl eher "quo errat demonstrator" statt "quod erat demonstrandum".
Natürlich gibts genug Beispiele wo objektorientierter Code Sachen kann, die prozeduraler Code nicht kann oder er schneller ist. Ich wurde aber darauf z.B. hingewiesen warum ich nicht Klassen anstatt Structs benutze, das empfinde ich als ineffektiv und oft brauch man den objekt orientierten Ansatz garnicht und kommt mit dem prozeduralen entweder mindstens genauso gut aus oder er ist sogar schneller. (Auch beim Code schreiben) Ich versteh nur nicht warum man überall immer OOP verwenden will und alles damit lösen will, es jedem aufzwingen will es möglichst oft zu verwenden, auch da wo es absolut garnicht unnötig ist, alles verkompiliziert und eventuell auch langsamer läuft, deshalb verwende ich es sparsam und da wo ich meine, dass es sinnvoll ist.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Ich weiß wie objektorientierte Programmierung funktioniert, ich habe selber schon mit ihr gearbeitet, ich glaube nicht, dass da C++ eine große Ausnahme darstellt.
[...] hinzu kommt noch, dass sie auf einem Heap gespeichert werden.
Ich werd die mir mal angucken, falls ich mich nochmal genauer mit dem Kram beschäftigen muss, was ich sicher werde, wenn ich ein Problem finde, welches hervorragend geeignet ist mit Klassen gelöst zu werden.
Dass es bei zunehmend größeren Projekten oft Vorteile mit sich bringt, da habe ich nie in Abrede gestellt, allerdings gibt es auch für prozedurale Sprachen genug Bibliotheken die mithalten können. Soweit ich weiß ist OpenGL z.B. komplett in C geschrieben.
Dieser Beitrag wurde bereits 18 mal editiert, zuletzt von »dot« (29.06.2012, 17:24)
Werbeanzeige