Programmierung in Assembler?

[Nanuk]

Hallo :)

Hat jemand Infos oder Links zum neuen Befehlssatz dieser Prozessoren? Besonders wenn man auf den GPU-Teil zugreifen will.

Schönen Abend noch. :)

[TTP]

bei nVidia heißt es CUDA.
google doch mal nach CUDA, da findest du ganz viel

[ich_]

Nur eine Frage:
Warum sollte man im Jahre 2010 noch in Assembler programmieren? Solange die Sprache zur Ausführung keine VM braucht, ist der Geschwindigkeitsverlust minimal (aka nicht fühlbar, kaum messbar).
Desweiteren kann man Assembly praktisch nicht ohne immensen Aufwand portieren.

[Nanuk]

Cuda kenn ich, und das ist ja nicht gerade Assembler. Wenn jetzt allerdings ne GPU integriert wird, hat man dann in ner Quelldatei Assemblercode gemischt mit Cuda-artigem-Code oder gibts extra Befehle für die GPU?

Trotzdem, danke für die nette Antwort. Schönen Abend noch :)

[Nanuk]

Assembler hat (wie C, Java, Python, etc.) alles Vor- und Nachteile. Die Portierbarkeit ist n Nachteil von Assembler. Stimmt. Aber es sei dir gesagt, dass kritische (auch etwas größere) Programmabschnitte locker mal um mehrere 100% schneller laufen, wenn mans in Assembler macht.

In 99,9% aller Fälle ist man vielleicht besser mit C (oder sonstewas) beraten ... aber in 0,01% (oder noch weniger) eben nicht.

Man kann nichts pauschalisieren.

Die meisten Leute hören "Compileroptimierung" und vertrauen blind darauf. Compiler machen sehr sehr oft großen Mist, vor allem an kritischen stellen. Und bevor jetzt jemand "Quellen?" oder "Beweise!" schreit, kann ich nur sagen: Disassembliert doch bitte einfach mal n kleines Programm. (So "Hello, World" Größe, vielleicht mit n paar Anweisungen mehr)

Der Compiler optimiert natürlich, aber da der Compiler oft nicht weiß, was der Programmierer ganau möchte, kann er gar nicht optimieren.

Also: Egal was man wie wo wann programmiert, man muss einfach abwägen, was am geeignetesten ist.

Schönen Tag noch an alle :)

PS: Wenn man Trojaner oder Malware programmiert, sollte man das sowieso immer mit Assembler machen. Schön klein und schnell. Einen simplen Server in weit unter 1KB bekommt man anders nicht hin. :)

[Jovis]

Mit Assembler verdient man heute in der IT nicht sein Geld.
Wenn man sich die Stellenanzeigen mal anschaut, kann man sich selber ein Bild von machen.

Gibst du ja schon selber zu, wenn du sagst dass man mit C in 99,9 % der Fälle gut beraten ist.

C ist quasi das heutige Assembler. Wenn man in Java ein Programm entwickelt, benutzt man das JNI und schreibt die kritischen Stellen mit C, wenn man Lust und Zeit hat. Oder schöneres Beispiel C++/CLI. Da vermischst du managed und nativen Code. Die wirklich kritischen Stellen, falls es welche gibt, machst du dann mit nativem Code.


Um Java oder .Net kommt heutzutage keiner mehr drumrum.

[Nanuk]

Gerade mit JNI ist Assembler genial. Wenn ich ne DLL oder lib mit C entwickle ist die mindestens 12 bis 15 KB groß. Mit Assembler isses ein bis zwei Kilibyte.

C ist bei Berechnungen usw. gerade mal doppelt so schnell wie Java. Dank JIT is Java schon Recht flott und reicht für fast alles. Wenns dann wirklich um Geschwindigkeit geht, dann doch bitte richtig und mit Assembler.

Beispiel für MD5 (auf nem älteren Rechner; is aber egal, kommt nur aufs Verhältnis an):

Referenzimplementierung in ANSI C ca. 2,3 Mio Hashes pro Sek.

Java mit MessageDigest ca. 1.2 Mio Hashes pro Sek.

Assembler (optimiert von mir und zwei anderen): ca. 4,3 Mio Hashes pro Sek.

Also bei Desktops oder Servern is Assembler (vielleicht) nicht so oft von Nöten. (Abgesehen von Low-Level-Sachen und Treiberentwicklung?)

Bei Mikrocontrollern kommt man nicht drum rum. (Aber darum gehts hier ja eigentlich nicht.)

PS: Gerade WEIL ich mit Assembler arbeite verdiene ich ein vielfaches von nem normalen Entwickler. Man sollte immer was Exotisches oder irgend eine Spezialisierung haben. :)

[firehorse]

Nanuk schrieb:
--------------------------------------------------------------------------------
> Cuda kenn ich, und das ist ja nicht gerade Assembler. Wenn jetzt allerdings
> ne GPU integriert wird, hat man dann in ner Quelldatei Assemblercode
> gemischt mit Cuda-artigem-Code oder gibts extra Befehle für die GPU?

Muss wohl. Zumal CPU und GPU immer noch getrennt auf dem Chip sind. Diese werden sich, wie man der Aussage des Updates entnehmen könnte, auch getrennt ansprechen lassen.

> Trotzdem, danke für die nette Antwort. Schönen Abend noch :)

Guten morgen wohl eher :)

[firehorse]

Nanuk schrieb:
--------------------------------------------------------------------------------
> PS: Gerade WEIL ich mit Assembler arbeite verdiene ich ein vielfaches von
> nem normalen Entwickler. Man sollte immer was Exotisches oder irgend eine
> Spezialisierung haben. :)

Bin zwar kein Assembler-Entwickler, kann mir aber gut vorstellen was Du meinst. Die Klasse macht es, nicht die Masse ;)
Es nicht viele Stellenangebote in solchen Bereichen. Aber es gibt auch nicht viele Unternehmen welche sich damit beschäftigen.

[FunnyName]

Nur weil es nicht viele Stellenanzeigen gibt heißt es nicht dass kein Bedarf da ist. Einen mittelmäßigen Java/C++ Entwickler findest du heute an jeder Ecke. Die Kosten fast nix und sind im Bedarfsfall austauschbar.

Assembler (u. Cobol ) Programmierer können sich bei uns 'ne goldene Nase verdienen. Die können ihre Arbeitsbedingungen diktieren etc. weil sie eben nicht austauschbar sind, weil es viel zu wenige gibt.

Und in Sachen Geschwindigkeit ist Assembler immer noch um ein vielfaches besser als Java oder C. Klar braucht man nicht an jeder Stelle optimale Performance. Aber wenn das kritisch ist, ist Assembler sicher das Maß der Dinge.

[Trollversteher]

>Und in Sachen Geschwindigkeit ist Assembler immer noch um ein vielfaches besser als Java oder C. Klar braucht man nicht an jeder Stelle optimale Performance. Aber wenn das kritisch ist, ist Assembler sicher das Maß der Dinge.

1.) Java ist eine Interpretersprache. Also ganz andere Anforderungen, ganz anderer Anwendungsbereich. Also eine vergleichende Formulierung wie "um vieles besser" ist hier ganz sicher nicht angebracht.

2.) C ist eine Compilersprache. Also auch die Formulierung "Java oder C" ist hier Quatsch. Dazu kommt, dass C/C++ Compiler auf den heute verwendeten PC-Prozessoren (AMD oder Intel) wesentlich optimierteren Code produzieren als es irgendein Assembler Programmierer hinbekommen könnte. Die Optimierungsmechanismen sind nämlich mittlerweile derart Komplex, dass kein normaler Mensch mehr wirklich durchblickt, in welchem Zustand sich ein Prozessor sich zum Zeitpunkt des Aufrufens seiner Routine gerade befindet - das können Compiler viel besser, weil die den "Überblick" bewahren können.

Assembler ist nur noch in den Bereichen Embedded- und Limited Device Entwicklung wirklich notwendig - also überall dort, wo kleine, einfache Prozessoren (z.B. ARM) mit beschränkten Ressourcen im Einsatz sind, wie in der Unterhaltungselektronik oder der Industrieautomatisierung. Aber selbst dort sind komplexere Systeme mit richtigem Betriebssystemen im Vormarsch (z.B. TV-Receiver, Handys) und damit schwinden auch dort immer mehr die Einsatzbereiche für Assemblerprogrammierung.

[Trollversteher]

>Die meisten Leute hören "Compileroptimierung" und vertrauen blind darauf. Compiler machen sehr sehr oft großen Mist, vor allem an kritischen stellen. Und bevor jetzt jemand "Quellen?" oder "Beweise!" schreit, kann ich nur sagen: Disassembliert doch bitte einfach mal n kleines Programm. (So "Hello, World" Größe, vielleicht mit n paar Anweisungen mehr)

Das ist ein Vorurteil, welches schon lange nicht mehr richtig ist. Heutige Compiler (zumindest auf PC Systemen) sind nachgewiesenermassen erheblich effizienter was Performance betrifft, als jedes Assemblerprogramm was Du schreiben könntest. Dazu sind die Prozessoren und deren Optimierungsmechanismen (z.B. Precaching oder Branchprediction, um mal ein paar schon etwas ältere Mechanismen zu nennen) mittlerweile viel zu komplex, als das man tatsächlich noch "per Hand" optimieren könnte um noch ein paar Zyklen mehr rauszuholen.

[Luki]

Trollversteher schrieb:
--------------------------------------------------------------------------------
> >Die meisten Leute hören "Compileroptimierung" und vertrauen blind darauf.
> Compiler machen sehr sehr oft großen Mist, vor allem an kritischen stellen.
> Und bevor jetzt jemand "Quellen?" oder "Beweise!" schreit, kann ich nur
> sagen: Disassembliert doch bitte einfach mal n kleines Programm. (So
> "Hello, World" Größe, vielleicht mit n paar Anweisungen mehr)
>
> Das ist ein Vorurteil, welches schon lange nicht mehr richtig ist. Heutige
> Compiler (zumindest auf PC Systemen) sind nachgewiesenermassen erheblich
> effizienter was Performance betrifft, als jedes Assemblerprogramm was Du
> schreiben könntest. Dazu sind die Prozessoren und deren
> Optimierungsmechanismen (z.B. Precaching oder Branchprediction, um mal ein
> paar schon etwas ältere Mechanismen zu nennen) mittlerweile viel zu
> komplex, als das man tatsächlich noch "per Hand" optimieren könnte um noch
> ein paar Zyklen mehr rauszuholen.


100 Punkte - auf PC Systemen behaupte ich auch, dass man fast immer gegen den Compiler verlieren wird...

[Trollversteher]

>100 Punkte - auf PC Systemen behaupte ich auch, dass man fast immer gegen den Compiler verlieren wird...

Eben. Imho hat Assembler heutzutage, mal angesehn von der Wartung älterer Software, nur noch in der Embedded- und Kleinstsystem-Entwicklung eine Daseinsberechtigung. Und spielt natürlich auch im Konsolenbereich noch eine Rolle, vor allem wenn exotische Prozessoren zum Einsatz kommen, bei denen die Compilerentwicklung noch nicht so fortgeschritten ist (z.B. beim Cell der PS3).

[Ich Ich]

Luki schrieb:
--------------------------------------------------------------------------------
> 100 Punkte - auf PC Systemen behaupte ich auch, dass man fast immer gegen
> den Compiler verlieren wird...

Und dank dem 'fast' hast du sogar zugegeben, dass es eben doch sein kann, dass ein guter ASM Entwickler besser vorankommt als ein compiler. pipeline stalling soll da mal genannt sein: versuch mal nen compiler zu finden, der da nicht strauchelt. Der Intel compiler ist da schon mal ne Ecke besser als gcc zum beispiel... )

[Bernd R]

@Nanuk
>Beispiel für MD5 (auf nem älteren Rechner; is aber egal, kommt >nur aufs Verhältnis an):

welche CPU war das ?
Du solltest das schon mal auf modernen CPU testen, würde mich interessieren und Werte posten.moderne CPU haben bessre Out of Order und register renaming features.Die I7 CPuŽs sind da nochmal besser.und das ist auch der Grund warum X86 ab AMD Athlon und Intel ab Core mehr Performance/MHZ liefern.

Daher ist es für alte CPU wichtiger, dass der Code optimial geschrieben ist.Neue sind da unempfindlicher.

allerdings haben moderne X86 so ne Art risc Core und machen nur wenig asm Befehle des X86 Befehssatz schnell.Die muss man kennen.

z.b Ziel Register die nicht das volle 32 bit (eax) register nutzen sondern nur 16 bit ax oder gar ah oder al sind auf vielen CPU sehr langsam.

das Compiler bei den wohl bekannten Benchmarks am besten sind, liegt an der Natur der Sache, weil ein Peephole Optimizer nach Codemustern sucht.

Und die Codemuster von specint oder specfp und andre Benches kennt jeder compiler und macht da den besten Code ;-)

ansonsten ist man in asm immer noch am schnellsten, wenn man weis was man tut, aber mit moderen CPU denke ich nicht, dass das mehr als 20-30% bringt,

ausser wenn man SIMD (SSE) assembler macht, da bringt es mehr das ist auch der Grund warum Programme wie ffmpeg viel SIMD assembler haben

[Schwarzes Tigerle]

Wenn Compiler so viel besser optimieren als Assembler-Programmer, warum merkt man dann nichts davon in der Ausführungsgeschwindigkeit?