Lohnt sich Assembler in C++ noch?
-
Hi, ich wollte mal wissen, ob sich Assembler Stücke in C++ Quellcodes bei den heutigen Optimierungen der Compiler überhaupt noch lohnen?
Vieleicht ja etwas bei 3DSpielen, aber lohnt sich der Aufwand Assembler einzubauen dann noch?MfG RoaN;
-
Hi.
In seltenen Faellen laesst sich da durchaus noch etwas mit Asm optimieren.
Ob das irgendwo auch noch wirtschaftlich ist, ist eine andere Frage.
-
also ich denke mal das selbst in 3d-games heute kein assembler mehr nötig ist / verwendet wird. früher, gerade bei software rendering (doom 1 / quake 1) natürlich durchaus... aber heutzutage hat man für sowas ja hardwarebeschleunigung.....
-
Danke, hat mich irgendwie interessiert.
MfG RoaN;
-
Aber als richtiger Programmierer sollte man sich IMHO schonmal mit ASM beschaeftigt haben (und quasi jeder richtige Programmierer hat sich auch schonmal mit ASM beschaeftigt). Man lernt einfach sehr viel ueber den PC, was man bei den Hochsprachen nicht lernt, oder nur sehr schwer. Wenn man seinen Rechner richtig versteht, bringt einem das eine ganze Menge. Und man lernt sparsam und effizient zu programmmieren. Und das ist nie verkehrt. Auch wenn heutzutage viel zu wenig darauf geachtet wird.
Ach ja, auf manchen Gebieten ist ASM auch heute noch aktuell. Zum Beispiel beim 'echten' Hacken. So Sachen wie wie Buffer Overflow (*g*) Schwachstellen ausnutzen und sowas. Aber das willst du natuerlich nicht machen.
-
Die meisten C-Compiler fuer PC's erzeugen saumaessigen Code, der nicht mal ansatzweise die Leistung der CPU ausreizt.
Schreib mal ein Programm in C und eins in Assembler, die beide dasselbe machen sollen. Du wirst sehen, dass halbwegs guter handgeschriebener Assembler-Code immer noch 5-10 mal schneller als entprechender C-Code ist; Optimizer hin oder her.
Die Billig-Versionen von Microsoft's Visual C++ haben uebrigens keinen Optimizer. GCC hat einen, hab ihn aber noch nicht unter die Lupe genommen. Hab nur mal gelesen, dass er Schrott sein soll, aber das ist schon wieder einige Jahre her (war bei den fruehen 3er-Versionen).
Kein mir bekannter Compiler fuer IA-32 CPUs nutzt automatisch den MMX/SSE/SSE2 Befehlssatz, oder die anderen, weniger gebraeuchlichen Befehle des Prozessors. Meist werden nur CALL, JMP, Jcc, PUSH, POP, MOV, ADD, SUB, MUL, DIV, NOT, AND, OR und die Shift- sowie FPU-Befehle benutzt. Ein Armutszeugnis.
Leider haben Intel und AMD angefangen, ihre CPUs auf die Compiler hin zu optimieren, wodurch nun ausgefallenere Befehle mehr uOPs brauchen.
D.h. statt INC muss man jetzt "ADD tgt,1" schreiben, z.B., um weniger uOPs zu verbrauchen.
Vorbei die Zeiten von IBM's Monster-Optimizern in IBM Visual Age for C++ ... frueher DER Referenz-Compiler ...
-
Geht's dir eh noch ganz gut?
-
Power Off schrieb:
Kein mir bekannter Compiler fuer IA-32 CPUs nutzt automatisch den MMX/SSE/SSE2 Befehlssatz, oder die anderen, weniger gebraeuchlichen Befehle des Prozessors.
mein devstudio macht das automatisch, egal ob mit intel oder microsoft compilern.
@topic
Ob assembler verwedet wird, hängt heutzutage vom programmierer ab ;), viele junge programmierer sind so auf libs fixiert, dass sie sich wohl auch selbst kein assembler zutrauen, obwohl sie sich mit boost wohl den rücken kratzen könnten...fähige leute (ps. das ist keine ironie).
man kann in vielen situationen noch einiges an performance rauskratzen, muss dann aber auch genau die zielplattform wissen. meine mathlib z.b. performt mit SSE um 50%-70% schneller als ohne, aber das auch nur auf p4, auf nem AthlonXP ist es ca 10% langsammer. und so ist das leider in jeder hinsicht. reicht ein andere cache (größe/geschwindigkeit), anderes mobo (z.b. mit/ohne dualchan) und schon kann eine optimierung in assembler sich ins negative ausdrücken.zum selbermachen:
was man sehr sehr einfach optimieren kann und was für jeden nützlich sein dürfte, wäre memcpy. bei AMD gibt es nen source wie man es wirklich fix macht, da bekommt man dann 2x performance bei memcpy und memset wenn man es denn verwenden möchte.rapso->greets();
-
Ich selbst habe mich einen kleinen Wettbewerb gestellt: Ein guter Bekannter und ich sollten ein Mandelbrot-Programm erstellen, dazu wurde uns die eigentliche Berechnung übergeben. Ich machte es in Assembler, der andere in C. Das Ergebnis war erschreckend! Mein Programm brauchte die doppelte Zeit um das gleiche Bild zu erzeugen!
Ein Blick in das Assemblierte C-Code erbrachte die Lösung! Der Compiler optimierte von sich aus die Befehle. Werte wurde in den Stack geschoben und für in 20 Befehlen weiter wieder rausgeholt zu werden und so weiter!
Natürlich könnte man solche Optimierungen in ein Assembler-Code bauen, aber wie lange würde ich dazu brauchen?
Ich selbst werde trotz dieses Erlebnisses weiter nebenbei in Assembler Programmieren. Alleine schon wegen der Einfachheit. Von Oben nach Unten!
Gruß Satyria
-
Sry, aber ich bin irgendwie nicht davon ueberzeugt, dass deine Assemblerskills allgemein referenzfaehig sind...
-
Das nicht, aber bezeichnend für solche "ich mach das mal in Assembler weil's ja viel schneller geht"-Vorhaben.
-
satyria1234 schrieb:
Ich selbst werde trotz dieses Erlebnisses weiter nebenbei in Assembler Programmieren. Alleine schon wegen der Einfachheit. Von Oben nach Unten!
Gruß Satyria
Es gibt in Assembler doch wohl Sprungbefehle ala goto.
-
Ich selbst finde X86 sehr unübersichtlich! Ich komme von einem 68xxx System. Da gab es genügend Register, die ich belegen konnte wie ich wollte. X86 rutscht das Register (bis überlauf) einfach weg! Das einzige was da hilft ist eine sehr gute struckturierte Programmierung! (Ich fange an und schau was passiert! (Meist Überlauf))
Gruß Satyria