Thema: L4-ähnlicher Kernel

[tev]

Ich habe vor einen L4-ähnlichen Kernel zu schreiben und will in auf meinen Pentium 4 Northwood optimieren. Dieses optimieren wird sogar so weit gehen, dass mein Kernel eventuell nicht auf anderen CPUs ausgeführt werden kann. Zum Beispiel will ich Hyperthreading und Sysenter/Sysexit nutzen. Und ich werde den Kernel in Assembler schreiben, erstens weil dies meine Lieblingssprache ist und man schöm optimieren kann.

Mich interessieren eure Meinungen dazu und wer fragen hat, kann ruhig fragen  .

[Svenska]

Assembler: Pfui. Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest. Wie an anderen Stellen auch schon verlinkt, weise ich auf dies hin; interessant mag auch dies sein, da wird noch explizit auf Pentium 4 verwiesen.

Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.

nicht-auf-anderen-CPUs-lauffähig: Das ist deine Sache, davon würde ich trotzdem abraten. Zumindest Kompatiblität nach "oben" (auf modernere CPUs) sollte es schon geben. Also bitte keine Errata ausnutzen.

Hyperthreading: Läuft auf eine SMP-Unterstützung hinaus. Es gibt ein paar wenige Unterschiede, da beide virtuelle CPUs sich stellenweise behindern können, aber grundsätzlich musst du "nur" mehrere CPUs unterstützen. Als Testsystem (gegen Fehler, nicht für Performance) wäre wahrscheinlich ein richtiges Multi-CPU-/Kern-System geeignet.

Sysenter/Sysexit: Das kann irgendwie jede modernere Intel-CPU, oder irre ich da?

Grundsätzlich ist meiner Meinung nach ein OS schon schwierig genug zu schreiben, das noch auf eine CPU hin zu optimieren, halte ich nicht für zielführend. Zumal man einen P4 nicht nutzen möchte (heiß, verglichen mit modernen CPUs ineffizient). Am Ende kannst du jederzeit mit "-O3 -march=pentium4 -mtune=pentium4" kompilieren, dann geht es auf weniger auch nicht mehr.

Was moderne Features angeht, sehe ich das etwas anders: Nutze sie gerne, rechne aber damit, dass dann nicht jeder testen kann.

Gruß,
Svenska

[freecrac]

Assembler: Pfui. Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest. Wie an anderen Stellen auch schon verlinkt, weise ich auf dies hin; interessant mag auch dies sein, da wird noch explizit auf Pentium 4 verwiesen.

Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.

Das bezweifel ich, denn die Möglichkeiten zur Optimierung eines x86-Opcodes wurden sowohl von AMD, sowie auch von Intel doch recht umfassend dokumentiert. Aber ich habe jetzt keine Lust hier eine nie endende Grundsatzdisskussion zu beginnen, die auch schon an hunderten anderen Stellen bereits geführt wurde, wo doch immer nur ein einziges Argument für die C-Programmierung übrig bleibt, das es nur eine Frage der Zeit ist bis man ein Assembler-Listing erstellt hat und das es in der Entwicklungsphase auch mehr Zeit verschlingt als ein C-Listing mit den selben funktionellen Umfang, sich nur deswegen wirtschaftlich nicht rechnet alles in Assembler zu schreiben. Mit rein privaten Interessen spielen solche Überlegungen aber eine eher untergeordnetere Rolle, wenn man die Lust dazu verspührt etwas in Assembler zu programmieren.

So kann ich mich mit der Programmiersprache C überhaupt nicht anfreunden und finde es so langweilig wie Basic-Programmierung, auch wenn dieser Vergleich etwas sehr hinkt.

Auf die Frage: Why use assembly antworterte Betov <http://rosasm.org>:
The price of freedom, so to say, and one of the reasons i am used to say that Assembly is an anarchist Language, whereas C (typicaly) is a fascist Language.

nicht-auf-anderen-CPUs-lauffähig:

Soll der Kernel denn überhaupt auf anderen CPUs laufen?

Das ist deine Sache, davon würde ich trotzdem abraten. Zumindest Kompatiblität nach "oben" (auf modernere CPUs) sollte es schon geben. Also bitte keine Errata ausnutzen.

Sollte es, oder wurde der Kernel eben nur für eine bestimmte CPU entwickelt?

Grundsätzlich ist meiner Meinung nach ein OS schon schwierig genug zu schreiben, das noch auf eine CPU hin zu optimieren, halte ich nicht für zielführend.

Du kannst ja gerne auch andere Ziele verfolgen, doch ich vermute das du hiebei möglicherweise eine andere Zielsetzung hast.

Dirk

[Svenska]

Die Frage ist, ob man in der Lage ist, sämtliche dokumentierten Optimierungsmöglichkeiten auch umfassend und überall ausnutzen zu können. Ich behaupte nein, du hast neben den offensichtlichen Dingen wie Branch Prediction und die Laufzeit der einzelnen Assemblerbefehle noch andere Dinge zu beachten, die sich wesentlich mehr auf die Gesamtlaufzeit auswirken; genannt seien hier die Cache-Miss-Rate, die Auslastung der Pipeline (beim P4 sehr viele Stufen) oder die zugrundeliegenden Algorithmen. Außerdem muss die Hardware auch korrekt und Effizient angesteuert werden, was nicht selbstverständlich ist (siehe Linux-Grafiktreibersituation für dokumentierte(!) Bausteine oder die übliche Windows-Treiberqualität).

Mal abgesehen davon bezweifle ich, dass du alle Befehle (inkl. FPU, MMX, SSE, 3Dnow) eines P4 mitsamt aller Nebeneffekte wie Parallelisierbarkeit, Ausführungsgeschwindigkeit, Pipelinerückwirkungen / Umsetzung in µOps, Errata und Randfälle im Kopf haben und immer optimal (auch in Kompromiss-Situationen) berücksichtigen kannst. Eventuell haben bestimmte Befehle in bestimmten Situationen (Kernel/User, PM mit/ohne PAE) auch andere Betriebsparameter. Außerdem kann eine theoretisch optimale Dokumentation praktisch immernoch großer Dreck sein.

Aber, du hast vollkommen recht, das hängt ausschließlich von der Zielsetzung ab.
Wenn es darum geht, ausschließlich in Assembler zu programmieren, okay.
Wenn es darum geht, ein OS zu schreiben, sollte man dies in einer Hochsprache tun. Es muss übrigens kein C sein.

Wenn man möchte, kann man es immernoch per Hand oder Zettel assemblieren.

Gruß,
Svenska

[kevin]

wo doch immer nur ein einziges Argument für die C-Programmierung übrig bleibt, das es nur eine Frage der Zeit ist bis man ein Assembler-Listing erstellt hat und das es in der Entwicklungsphase auch mehr Zeit verschlingt als ein C-Listing mit den selben funktionellen Umfang, sich nur deswegen wirtschaftlich nicht rechnet alles in Assembler zu schreiben. Mit rein privaten Interessen spielen solche Überlegungen aber eine eher untergeordnetere Rolle, wenn man die Lust dazu verspührt etwas in Assembler zu programmieren.

Die benötigte Zeit ist die eine Sache (und ja, die ist mir auch in der Freizeit nicht ganz unwichtig, wenn es mir darum geht, irgendein Problem gelöst zu bekommen und nicht nur darum, ein bisschen Assembler zu spielen), das andere ist die Fehleranfälligkeit. Der Compiler einer Hochsprache kann dir in vielen Fällen auf die Finger klopfen, wenn du Mist baust bzw. Mist erst gar nicht zulassen (Typisierung, Aufrufkonventionen, usw.), ein Assembler kann das nicht. Es kommt also die Zeit beim Debugging und fehlendes Vertrauen in die Funktionsfähigkeit dazu. Lesbarkeit ist natürlich auch ein anderes Problem.

Letztendlich bleibt nur ein einziger Grund, warum man Assembler schreibt: "Weil ich kann". Objektiv sinnvoll ist es für alles, was über eine Handvoll Zeilen hinausgeht, nicht.

[freecrac]

Die Frage ist, ob man in der Lage ist, sämtliche dokumentierten Optimierungsmöglichkeiten auch umfassend und überall ausnutzen zu können.

Wenn man die Dokumente dafür hat, dann ist es durchaus möglich. Hier habe ich mal eine kleine Liste davon zusammengestellt:

Intel® Architecture Optimization Reference Manual:
http://www.intel.com/design/pentiumii/manuals/245127.htm

ftp://download.intel.com/design/pentiumii/manuals/24512701.pdf

Intel® 64 and IA-32 Architectures Software Developer's Manuals:
http://developer.intel.com/products/processor/manuals/index.htm

Optimizing subroutines in assembly language
An optimization guide for x86 platforms
By Agner Fog. Copenhagen University College of Engineering:
http://www.agner.org/optimize/optimizing_assembly.pdf

The microarchitecture of Intel, AMD and VIA CPUs
An optimization guide for assembly programmers and
compiler makers By Agner Fog. Copenhagen University College of Engineering:
http://www.agner.org/optimize/microarchitecture.pdf

Instruction tables Lists of instruction latencies, throughputs and microoperation
breakdowns for Intel, AMD and VIA CPUs By Agner Fog. Copenhagen University College of Engineering:
http://www.agner.org/optimize/instruction_tables.pdf

AMD Athlon™ Processor x86 Code Optimization Guide:
http://support.amd.com/us/Processor_TechDocs/22007.pdf

Software Optimization Guide for AMD64 Processors:
http://www.phatcode.net/res/252/files/25112.pdf

Ich behaupte nein, du hast neben den offensichtlichen Dingen wie Branch Prediction und die Laufzeit der einzelnen Assemblerbefehle noch andere Dinge zu beachten, die sich wesentlich mehr auf die Gesamtlaufzeit auswirken; genannt seien hier die Cache-Miss-Rate, die Auslastung der Pipeline (beim P4 sehr viele Stufen) oder die zugrundeliegenden Algorithmen. Außerdem muss die Hardware auch korrekt und Effizient angesteuert werden, was nicht selbstverständlich ist (siehe Linux-Grafiktreibersituation für dokumentierte(!) Bausteine oder die übliche Windows-Treiberqualität).


Mal abgesehen davon bezweifle ich, dass du alle Befehle (inkl. FPU, MMX, SSE, 3Dnow) eines P4 mitsamt aller Nebeneffekte wie Parallelisierbarkeit, Ausführungsgeschwindigkeit, Pipelinerückwirkungen / Umsetzung in µOps, Errata und Randfälle im Kopf haben und immer optimal (auch in Kompromiss-Situationen) berücksichtigen kannst. Eventuell haben bestimmte Befehle in bestimmten Situationen (Kernel/User, PM mit/ohne PAE) auch andere Betriebsparameter. Außerdem kann eine theoretisch optimale Dokumentation praktisch immernoch großer Dreck sein.

Daneben kann man die Laufzeit ja auch messen und so Flaschenhälse aufspüren.

Aber, du hast vollkommen recht, das hängt ausschließlich von der Zielsetzung ab.
Wenn es darum geht, ausschließlich in Assembler zu programmieren, okay.
Wenn es darum geht, ein OS zu schreiben, sollte man dies in einer Hochsprache tun.

Es muss übrigens kein C sein.

Wenn man möchte, kann man es immernoch per Hand oder Zettel assemblieren.

Gruß,
Svenska

Ok, im Endeffekt spielt es gar keine Rolle wie eine optimale Byte-Folge zustande kommt.
Aber das ein C-Compiler immer den besten Code erstellt, das ist nur eine weit verbreitete Behauptung die auch schon mehrfach widerlegt wurde.

Dirk

[freecrac]

wo doch immer nur ein einziges Argument für die C-Programmierung übrig bleibt, das es nur eine Frage der Zeit ist bis man ein Assembler-Listing erstellt hat und das es in der Entwicklungsphase auch mehr Zeit verschlingt als ein C-Listing mit den selben funktionellen Umfang, sich nur deswegen wirtschaftlich nicht rechnet alles in Assembler zu schreiben. Mit rein privaten Interessen spielen solche Überlegungen aber eine eher untergeordnetere Rolle, wenn man die Lust dazu verspührt etwas in Assembler zu programmieren.

Die benötigte Zeit ist die eine Sache (und ja, die ist mir auch in der Freizeit nicht ganz unwichtig, wenn es mir darum geht, irgendein Problem gelöst zu bekommen und nicht nur darum, ein bisschen Assembler zu spielen), das andere ist die Fehleranfälligkeit. Der Compiler einer Hochsprache kann dir in vielen Fällen auf die Finger klopfen, wenn du Mist baust bzw. Mist erst gar nicht zulassen (Typisierung, Aufrufkonventionen, usw.), ein Assembler kann das nicht. Es kommt also die Zeit beim Debugging und fehlendes Vertrauen in die Funktionsfähigkeit dazu. Lesbarkeit ist natürlich auch ein anderes Problem.

Letztendlich bleibt nur ein einziger Grund, warum man Assembler schreibt: "Weil ich kann". Objektiv sinnvoll ist es für alles, was über eine Handvoll Zeilen hinausgeht, nicht.

Auch diese Umschreibung mit den Handvoll Zeilen ist nur eine Behauptung die bereits widerlegt wurde, sich aber trotzdem hartnäckig unter den C-Programmieren verbreitet.

http://www.menuetos.net/
MenuetOS is an Operating System in development for the PC written entirely in 32/64 bit assembly language. Menuet64 is released under License and Menuet32 under GPL. Menuet supports 32/64 bit x86 assembly programming for smaller, faster and less resource hungry applications.

...

Ein ähnlich schwaches Argument ist es die Menge an C-Programmierern mit den wenigen Assembler-Programmierer zu vergleichen und über eine derartige Quantität eine Aussage über die Qualität vorzunehmen. Ein milliarde Fliegen können sich ja nicht irren......

Aber gut, das ist eine endlose Diskussion, die auf dieser Ebene zu keinem Resultat führt.

Dirk

[kevin]

Wie leitest du aus der Existenz von MenuetOS ab, dass dieser Weg objektiv sinnvoll war und die Entwickler nicht in einer anderen Sprache schneller/fehlerfreier/allgemein besser ans Ziel gekommen wären?

Ich sag ja nicht, dass man mit Assembler nichts größeres entwickeln kann. Ich sage nur, dass es sinnvolleres gibt, wenn das Programmieren in Assembler nicht Teil der Zielsetzung ist.

[bluecode]

Aber das ein C-Compiler immer den besten Code erstellt, das ist nur eine weit verbreitete Behauptung die auch schon mehrfach widerlegt wurde.

Gut, dass das keiner behauptet hat.

Auch diese Umschreibung mit den Handvoll Zeilen ist nur eine Behauptung die bereits widerlegt wurde, sich aber trotzdem hartnäckig unter den C-Programmieren verbreitet.

Und wo/wie wurde die widerlegt?

[freecrac]

Wie leitest du aus der Existenz von MenuetOS ab, dass dieser Weg objektiv sinnvoll war und die Entwickler nicht in einer anderen Sprache schneller/fehlerfreier/allgemein besser ans Ziel gekommen wären?

Wenn man schneller als "allgemein besser ans Ziel kommen" interpretiert ist das wohl richtig, doch diese Interpretation teilt nun mal nicht jeder und Fehler sind doch auch dazu da, um daraus zu lernen und das ist allgemein betrachtet bei C auch nicht grundlegend anders und das man bei der Verwendung von Assembler einiges mehr lernen kann und damit auch die Möglichkeit steigt mehr Fehler zu machen als bei Hochsprachen, ist ja wohl auch kein Geheimnis.

Ich sag ja nicht, dass man mit Assembler nichts größeres entwickeln kann. Ich sage nur, dass es sinnvolleres gibt, wenn das Programmieren in Assembler nicht Teil der Zielsetzung ist.

Je komplexer eine Struktur geworden ist, desto unwahrscheinlicher ist es das ein Compiler optimaler arbeiten kann als ein Mensch der die Probleme von Hand in den Griff bekommen kann, weil er eben alle Möglichkeiten in Betracht ziehen kann, womit ein Compiler letztendlich nie so umfangreich gestaltet werden könnte, um eine derartige Optimierung in jeden Fall hin zu bekommen. Auch aus diesem Grund werden zeitkritische Operationen nach wie vor in Assembler programmiert, ggf. mit Inline-Assembler.

Dirk

[freecrac]

Aber das ein C-Compiler immer den besten Code erstellt, das ist nur eine weit verbreitete Behauptung die auch schon mehrfach widerlegt wurde.

Gut, dass das keiner behauptet hat.

Hahaha..

Auch diese Umschreibung mit den Handvoll Zeilen ist nur eine Behauptung die bereits widerlegt wurde, sich aber trotzdem hartnäckig unter den C-Programmieren verbreitet.

Und wo/wie wurde die widerlegt?

Z.B. hat MenuetOS mehr als eine Handvoll Zeilen.

Dirk

[bluecode]

Hahaha..

Das war kein Witz. Du hast einfach die Behauptung verdreht und das verdrehte widerlegt. Von uns hat niemand behauptet, dass Compiler (immer) optimalen (was auch immer das sein soll) Code ausspucken. Es wurde nur behauptet, dass es für Menschen sehr schwer sein dürfte an die Optimierung des Compilers (bei gleicher Funktionalität) heranzukommen und va. extrem zeitaufwändig und wissensintensiv. Was du auch nicht bewiesen hast, ist dass MenuetOS in irgendeiner Weise optimiert ist, sondenr nur, dass es ein AssemblerOS mit mehr als 4 Zeilen gibt.
Meine Erfahrung aus diesem Forum sagt mir aber, dass die mit einem OS in Assembler anfangen, relativ früh scheitern (meist Bootloader). Desweiteren sagt mir meine Erfahrung aus dem Forum, dass die meisten Assembler als Bumpersticker anstelle von "hochoptimiert" verwenden, aber im Endeffekt garnichts von Optimierung dahinter ist, weil meistens das Wissen im Bereich Assembler, Optimierung, Algorithmen & Datenstrukturen, Prozessoraufbau und -funktionsweise fehlt. Was bei weitem nicht heißen soll, dass ich die hätte. Aber ich weiß zumindest, dass ich klaffende Wissenslücken habe. Das muss auch nicht heißen, dass dir das Wissen fehlt. Ich will nur darauf hinweisen, dass es für andere Forumbenutzer nur bedingt nützlich ist, solche auf sie nicht zutreffende Meinungen, zu verteidigen.

[tev]

Irgendwie hatte ich geahnt, dass es wieder diese Compiler vs. Assembler Diskussion wird .

Aber ich mag es einfach Assembler zu programmieren und zu optimieren, das ist für mich ein schönes Gefühl, weil ich weiß, dass _ICH_ meinen Code schneller gemacht hab.

Svenska: Sysenter und Sysexit gibt es glaub ich sogar schon länger als den Pentium 4, aber was ich meine ist, dass AMD CPUs damit vielleicht nicht können, aber später wäre es ja recht interessant das zu testen.

[freecrac]

Hahaha..

Das war kein Witz. Du hast einfach die Behauptung verdreht und das verdrehte widerlegt.

Das stimmt nicht so ganz.

Von uns hat niemand behauptet, dass Compiler (immer) optimalen (was auch immer das sein soll) Code ausspucken.

Na doch, es wurde behauptet Zitat von: Svenska am 18. Januar 2011, 23:15:
"Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest."
...und abgeleitet davon kann man schon davon ausgehen das damit auch gemeint war, dass Compiler immer einen optimaleren Code ausspucken.
Was sollte es denn sonst bedeuten?

Es wurde nur behauptet, dass es für Menschen sehr schwer sein dürfte an die Optimierung des Compilers (bei gleicher Funktionalität) heranzukommen und va. extrem zeitaufwändig und wissensintensiv.

Das es zeitaufwändig und wissensintensiv ist, das will ich ja auch gar nicht betreiten. Aber das wurde eben nicht nur behauptet, sondern auch das gute C-Compiler die CPU besser kennen, als ein "Programmierer" es je kennen lernen könnte.

Was du auch nicht bewiesen hast, ist dass MenuetOS in irgendeiner Weise optimiert ist, sondenr nur, dass es ein AssemblerOS mit mehr als 4 Zeilen gibt.

Stimmt, in diesem Zusammenhang war nicht die Rede von einer Optimierung, damit wurde nur die Behauptung widerlegt, das alles was über eine Handvoll Assemblercode hinausgeht nicht objektiv sinnvoll sei. Ein ganzes OS besteht ja wohl aus mehr als nur eine Handvoll Zeilen und ein ganzes OS ist ja wohl auch objektiv sinnvoll genug, oder etwa nicht?

Und da du gerade von "Verdrehung" redest, es steht dir natürlich frei verschiedene Antworten von mir willkürlich zusammenzuwürfeln, obwohl jede einzelne Anwort für sich alleine jeweils auf eine unterschiedliche Äusserung abzielte und zusammengelegt eine ganz andere Bedeutung bekommt, die ich in diesem Zusammnhang gar nicht beabsichtigt hatte.

Meine Erfahrung aus diesem Forum sagt mir aber, dass die mit einem OS in Assembler anfangen, relativ früh scheitern (meist Bootloader). Desweiteren sagt mir meine Erfahrung aus dem Forum, dass die meisten Assembler als Bumpersticker anstelle von "hochoptimiert" verwenden, aber im Endeffekt garnichts von Optimierung dahinter ist, weil meistens das Wissen im Bereich Assembler, Optimierung, Algorithmen & Datenstrukturen, Prozessoraufbau und -funktionsweise fehlt.

Da ich dieses Forum noch nicht gut genug kenne und es im Vergleich zu C-Programmierern nur wenige Assembler-Programmierer gibt, kann ich dir hierbei auch nur zustimmen.

Was bei weitem nicht heißen soll, dass ich die hätte. Aber ich weiß zumindest, dass ich klaffende Wissenslücken habe. Das muss auch nicht heißen, dass dir das Wissen fehlt.

Dann sind wir schon zwei mit klaffenden Wissenslücken, auch ich befinde mich noch in der Lern-Phase.

Ich will nur darauf hinweisen, dass es für andere Forumbenutzer nur bedingt nützlich ist, solche auf sie nicht zutreffende Meinungen, zu verteidigen.

Ja das kann ich nachvollziehen. Denn so wie du unterschiedliche Aussagen von mir zusammenwürfelst ergibt sich daraus eine ganz andere Meinung, die ich auch gar nicht verteidigen möchte, da hier ein völlig anderer Sinn von dir hineininterpretiert wurde, den ich so niemals geaussert haben wollte.

Dirk

[freecrac]

Irgendwie hatte ich geahnt, dass es wieder diese Compiler vs. Assembler Diskussion wird .

Damit muss man halt als Assembler-Programmierer immer rechnen.

Aber ich mag es einfach Assembler zu programmieren und zu optimieren, das ist für mich ein schönes Gefühl, weil ich weiß, dass _ICH_ meinen Code schneller gemacht hab.

Ich respektiere deine Arbeit und erwarte auch, dass dir auch der Respekt im gleichen Umfang von C-Programmierern zu Teil wird, genauso wie wir die Arbeit von C-Programmierern respektieren. Gelegentlich wird ja auch behauptet das Assembler-Programmierer, wenn sie über die Beweggründe reden warum sie in Assembler programmieren, damit die Arbeit von C-Programierer weniger respektieren würden. Das stimmt aber nicht und das möchte ich in diesem Zusammenhang auch noch einmal betonen. Assemblerprogrammierer respektieren auch die Arbeit von C-Programmierern, auch dann wenn unsere Gründe etwas in Assembler zu programmieren für uns wichtiger sind, als jene Gründe die C-Progerammierer für ihre Arbeit haben. Auch kennen die meisten Assembler-Programmierer die Beweggründe der C-Progerammierer etwas in C zu programmieren recht genau, es ist ja nicht so als wenn hier etwas völlig Neues angepriesen wird, wenn wieder einmal versucht wird die Arbeit eines Assembler-Proagrammierers als etwas Unmodernes, Unwichtiges und als sinnloses Unterfangen zu definieren. Wir Assembler-Programmierer wissen es schon genau, warum wir darin einen Sinn erkennen können etwas in Assembler zu programmieren. Derartige Belehrungen sind in diesem Zusammenhang somit einfach nur respektlos, wenn hier solche abfälligen Bemerkungen verwendet und eingestreut werden.

Dirk

[kevin]

Je komplexer eine Struktur geworden ist, desto unwahrscheinlicher ist es das ein Compiler optimaler arbeiten kann als ein Mensch der die Probleme von Hand in den Griff bekommen kann, weil er eben alle Möglichkeiten in Betracht ziehen kann, womit ein Compiler letztendlich nie so umfangreich gestaltet werden könnte, um eine derartige Optimierung in jeden Fall hin zu bekommen.

Umgekehrt wird ein Schuh draus: Bei was kleinem kann man es sich noch leisten, sich die Zeit zu nehmen, es im Detail zu optimieren. Bei was großem, komplexem, bei dem man viele verschiedene Fälle beachten muss, ist die Maschine im Vorteil, weil an Stelle der Kreativität die Speichergröße relevanter wird.

Auch aus diesem Grund werden zeitkritische Operationen nach wie vor in Assembler programmiert, ggf. mit Inline-Assembler.

Genau, und das sind meistens sehr kleine, überschaubare Stellen.

[kevin]

Svenska: Sysenter und Sysexit gibt es glaub ich sogar schon länger als den Pentium 4, aber was ich meine ist, dass AMD CPUs damit vielleicht nicht können, aber später wäre es ja recht interessant das zu testen.

Wenn du kompatibel sein willst, nimm im PM sysenter und im LM syscall.

[freecrac]

Je komplexer eine Struktur geworden ist, desto unwahrscheinlicher ist es das ein Compiler optimaler arbeiten kann als ein Mensch der die Probleme von Hand in den Griff bekommen kann, weil er eben alle Möglichkeiten in Betracht ziehen kann, womit ein Compiler letztendlich nie so umfangreich gestaltet werden könnte, um eine derartige Optimierung in jeden Fall hin zu bekommen.

Umgekehrt wird ein Schuh draus: Bei was kleinem kann man es sich noch leisten, sich die Zeit zu nehmen, es im Detail zu optimieren.

Ich kann es mir auf jeden Fall leisten diese Zeit mir zu nehmen ob es nun komplexer wird oder auch nicht, da ich bei der Programmierung in keinerlei wirtschaftlichen Abhängigkeiten stehe und alle meine Aktivitäten rund um Computer als ein reines Hobby betrachte. Das Argument mit der Zeit die man dafür aufwendet ist für mich also völlig bedeutungslos. Somit brauche ich mir diesen Schuh doch gar nicht erst anziehen und kann mir alle Zeit der Welt nehmen einen komplexeren Code auch von Hand zu optimieren.

Bei was großem, komplexem, bei dem man viele verschiedene Fälle beachten muss, ist die Maschine im Vorteil, weil an Stelle der Kreativität die Speichergröße relevanter wird.

Die Maschine(Compiler) ist hier lediglich im Geschwindigkeitsvorteil, mehr aber auch nicht, denn neben der höheren Anzahl an Möglichkeiten kreativ den Code mit Assembler zu entwickeln, kann man mit dem verwendeten Speicher genauso sparend umgehen und meist werden die Anwendungen selber sogar noch viel kleiner als Anwendungen die mit einem C-Compiler entwickelt wurden. So ist auch dieses Argument für mich völlig irrelevant.

Auch aus diesem Grund werden zeitkritische Operationen nach wie vor in Assembler programmiert, ggf. mit Inline-Assembler.

Genau, und das sind meistens sehr kleine, überschaubare Stellen.

Daran zeigt sich doch schon wie schlecht die C-Compiler arbeiten, wenn sie nicht mal in der Lage dazu sind so kleine Teile so optimal zu gestalten, das man hierbei überhaupt noch auf Assembler-Code zurückgreifen muss, um eine bestmögliche Ausführungsgeschwindigkeit zu erzielen.

Dirk

[MNemo]

Es bezweifelt hier niemand, dass ein Mensch theoretisch in der Lage ist den Optimalen Assembler-Code zu schreiben.
Und es behauptet hier auch niemand, dass ein Compiler den Optimalen Code erzeugt.

Und wenn das Programm schon fertig ist, schafft man es auch [in endlicher Zeit], das ganze in Assembler zuschreiben, so dass der Code besser ist als von einem Compiler erzeugt. Aber für gewöhnlich schreibt man Programme iterativ, d. h. es kommt immer was dazu und mit jedem Code, der dazu kommt und/oder der sich ändert sieht der Optimale Code anders aus. Was zu exponentiell wachsenden Aufwand wird, dein Assembler Code zu warten und optimieren. Wenn du dir die Arbeit machst, dann gut, aber die Wenigsten werden sich die Arbeit machen, was am Ende dann zu einem (viel) schlechterem Ergebnis führt, als dem Resultat eines modernen Compilers.

Genau, und das sind meistens sehr kleine, überschaubare Stellen.

Daran zeigt sich doch schon wie schlecht die C-Compiler arbeiten, wenn sie nicht mal in der Lage dazu sind so kleine Teile so optimal zu gestalten, das man hierbei überhaupt noch auf Assembler-Code zurückgreifen muss, um eine bestmögliche Ausführungsgeschwindigkeit zu erzielen.

Dann sagst du auch, das eine Funkuhr die an einem Tag eine Zehntel Sekunde falsch geht, ungenauer ist als eine herkömmliche Uhr, die in einer Woche um eine Zehntel Sekunde falsch geht? Also die Funkuhr geht auch nach einem Jahr und mehr nur eine Zehntel-Sekunde [falsch]. Ergo kann ich deinen Schluss hier auf schlechte Compiler nicht verstehen. Manchmal ist halt für kleine Sachen der sonst "schlechtere" Weg doch der bessere.

[XanClic]

Assemblerprogrammierer respektieren auch die Arbeit von C-Programmierern, auch dann wenn unsere Gründe etwas in Assembler zu programmieren für uns wichtiger sind, als jene Gründe die C-Progerammierer für ihre Arbeit haben.

Ich habe lange genug in Assembler programmiert, um ganz genau zu wissen, wieso ich jetzt lieber C nehme.