Lowlevel
Lowlevel => OS-Design => Thema gestartet von: tev am 18. January 2011, 21:11
-
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 :-D.
-
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 (http://dl.fefe.de/optimizer-isec.pdf) hin; interessant mag auch dies (http://dl.fefe.de/bignum.pdf) 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
-
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 (http://dl.fefe.de/optimizer-isec.pdf) hin; interessant mag auch dies (http://dl.fefe.de/bignum.pdf) 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
-
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
-
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.
-
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
-
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
-
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.
-
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. :wink:
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?
-
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
-
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. :wink:
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
-
Hahaha..
Das war kein Witz. Du hast einfach die Behauptung verdreht und das verdrehte widerlegt. :wink: 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.
-
Irgendwie hatte ich geahnt, dass es wieder diese Compiler vs. Assembler Diskussion wird :-D.
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. :-)
-
Hahaha..
Das war kein Witz. Du hast einfach die Behauptung verdreht und das verdrehte widerlegt.:wink:
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
-
Irgendwie hatte ich geahnt, dass es wieder diese Compiler vs. Assembler Diskussion wird :-D.
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
-
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.
-
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.
-
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
-
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.
-
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.
-
Aber es ist doch wirklich egal in welcher Sprache ich mein OS/Kernel schreib :-D.
Jeder sollte Spaß dabei haben und davon habe ich halt einfach am meisten mit Assembler, wenn jemand lieber in C programmiert, dann ist das auch vollkommen in Ordnung. :-)
Anders ist es halt, wenn die Zeit, die man für die Entwicklung von etwas braucht, eine Rolle spielt, aber das ist meistens bei Hobbyprojekten zweitrangig.
-
Aber es ist doch wirklich egal in welcher Sprache ich mein OS/Kernel schreib :-D.
Selbst verständlich. Nur solltest du die Sprache deiner Wahl nicht aus den falschen Gründen wählen. Spaß ist bei Hobby-Projekten natürlich völlig ausreichend. Und, dass du weniger Respektiert wirst weil du Spaß an Assembler hast ist natürlich auch völliger Blödsinn. Wir Programmieren ja auch selbst alle hier und da in Assembler (von den Theoretikern hier mal abgesehen xD).
-
Anders ist es halt, wenn die Zeit, die man für die Entwicklung von etwas braucht, eine Rolle spielt, aber das ist meistens bei Hobbyprojekten zweitrangig.
Naja, wenn die Zeit dann praktisch gesehen den Unterschied macht, ob ich auch irgendwann mal ein Ergebnis bekomme oder ob es für immer unbenutzbare Baustell bleibt, dann sehe ich das schon auch mal anders. ;)
-
Aber nochmal zu meinem Kernel, den ich ja schreib :-).
Ich werde ja auch Syscalls zur Verfügung stellen, wobei ich nicht genau weiß, welche es sein sollten.
Weil L4 selber stellt ja nur ein paar zur Verfügung nämlich ein paar Funktionen für IPC, Memory Management, Prozesse und noch eine Funktion um die restliche Zeit der Zeitscheibe einem anderen Prozess zur Verfügung stellen.
Wobei ich mir nicht sicher bin, welche ich implementieren soll, weil mein Ziel ist es ja so wenig wie nötig im Kernel zu implementieren.
-
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.
Ja hierbei kann ich vollkommen zustimmen.
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.
Ein schlechter Weg ist besser als gar kein Weg, daran habe ich keine Zeifel und soooo schlecht sind die Compiler für das was sie in der Menge leisten nun auch wieder nicht. Sonst gäbe es viele Anwendungen noch nicht.
Man kann auch vermuten das es ohne Hochsprachen unmöglich ist die heutigen Informationswege zu gestalten. Eine riesige Datenflut komt auf uns zu es wird immer schneller und umfangreicher.
Das was wir heute kennen ist doch erst der Anfang.
Wer Zeit und Lust dazu hat kann aber trotzdem mit Assembler etwas programmieren.
Dirk
-
Anders ist es halt, wenn die Zeit, die man für die Entwicklung von etwas braucht, eine Rolle spielt, aber das ist meistens bei Hobbyprojekten zweitrangig.
Naja, wenn die Zeit dann praktisch gesehen den Unterschied macht, ob ich auch irgendwann mal ein Ergebnis bekomme oder ob es für immer unbenutzbare Baustell bleibt, dann sehe ich das schon auch mal anders. ;)
Oha, zwischen unbenutzbar und unvollendet ist ganz gewiss noch ein sehr weiter Weg. 8-)
Dirk
-
Um mich auch mal in die Diskussion einzumischen ;)
Das man in C programmiert heißt aber noch lange nicht das man auch eher und/oder schneller fertig wird (wenn man das überhaupt schafft) als jemand der in Assembler programmiert.
Es gibt genug Versuche ein OS zu programmieren, die in C geschrieben sind, die nicht alzu weit gekommen sind und genauso gibt es einige (ich möchte das Wort viele in dieser Hinsicht nicht benutzen) OS die verdammt weit gekommen sind (spontan fallen mir nur 2 ein, V2OS und menuetos).
Ich sag mir immer dem jedem das seine. Auch ich habe mit Assembler angefangen und bin halbwegs weit gekommen, aber als es dann losging das ich ELF-Dateien parsen musste, wurde es dann wirklich unschön (warum weiß man wenn man mal meinen C-Code dazu gelesen hat ;) ). Aber ansonsten hatte ich mit Assembler schneller erfolge, konnte Algos besser und schneller umsetzen und der Code war wesentlich kleiner.
Assembler sollte man sich aber auch nur "antun" wenn man sich damit auskennt, ansonsten ist C eindeutig besser.
-
Bei den schnellen Erfolgen kann ich zustimmen, da man näher an der Maschine arbeitet, liegt weniger Krempel dazwischen (insbesondere die Toolchain ist bei Assembler sehr hergestellt).
Den kleineren Code würde ich so nicht bestätigen. Wenn es noch wenig Code ist, wirkt das oft (zurecht) so, bei komplexeren Dingen ist das eher andersrum - je unübersichtlicher es wird, desto eher tendiert man dazu, Dinge ineffizient oder mehrfach zu erledigen. Außerdem darf der Compiler eine Abwägung zwischen Codegröße und Effizienz (loop-unrolling) treffen. Der Grad der Unübersichtlichkeit hängt außerdem direkt mit der Wahl der Programmiersprache zusammen, ist aber nicht ausschließlich davon abhängig.
Nichttriviale Algorithmen lassen sich in einer Hochsprache eigentlich immer besser/eleganter und vor allem wiederverwertbarer umsetzen.
-
Nichttriviale Algorithmen lassen sich in einer Hochsprache eigentlich immer besser/eleganter und vor allem wiederverwertbarer umsetzen.
Dem kann ich so nicht zustimmen. Was stimmt ist das sie wiederverwertbarer sind, aber nicht unbedint besser/eleganter.
Das Problem für mich ist halt, das ich mich irgendwann daran gewöhnt hatte dass ich in Assembler "denken" konnte und da viel mir der Umstieg auf eine Hochsprache schwer (das ist bei bestimmten Dingen noch immer so).
Ganz konkret gab es da mal einen Algo den ich versucht habe von Assembler in eine Hochsprache zu übersetzen und damit ich keine goto´s verwende, habe ich einige viele if-Zweige dringehabt und es gab verdammt viel Code-Doppelung.
Die Sache mit den nicht trivialen Algos ist allerdings die, das wenn man als Bsp ne Sprache wie Logic/Prolog/Haskel usw. nimmt, man vllt Code schreibt der schön aussieht und "leicht" lesbar ist, aber wie der Compiler das dann umsetzt entzieht sich eigentlich fast allen Programmierern.
Ein einfaches Bsp wäre Quicksort in Haskel, ich erinnere mich dass das nicht mehr als 2 oder 3 Zeilen war, aber was macht der Compiler daraus?
Das nächste ist, das es schwierig ist einen Compiler richtig zu steuern, ihm also zu sagen, die Funktion ist wichtig, hier jetzt die und die Optimierung machen, die Funktion ist nicht so wichtig, da muss nicht so optimiert werden und die Funktion soll auf Größe optimiert werden.
Gut dazu gibt es #pragma, aber ich bin mir nicht sicher ob das im Standard ist oder ob das ne gcc Erweiterung ist.
Was mich auf jeden Fall an z.B. C stört, ist das ständige herumgecaste ;) Ich will nunmal auch vernünftig mit Pointern rechnen können!
Aber mal back2topic.
Was willst du denn alles im Kernel haben? Wenn du dich an L4 orientieren willst, dann implementiere doch einfach die API, da ist dann aber wirklich so gut wie nichts im Kernel und ganz einfach stelle ich mir das auch nicht vor.
-
Das Problem für mich ist halt, das ich mich irgendwann daran gewöhnt hatte dass ich in Assembler "denken" konnte und da viel mir der Umstieg auf eine Hochsprache schwer (das ist bei bestimmten Dingen noch immer so).
Das ist kein Argument für Assembler. Wenn du in einer Sprache geübt bist, kannst du darin Dinge immer besser umsetzen, als in einer Sprache, in der du nicht geübt bist. :roll:
Ganz konkret gab es da mal einen Algo den ich versucht habe von Assembler in eine Hochsprache zu übersetzen und damit ich keine goto´s verwende, habe ich einige viele if-Zweige dringehabt und es gab verdammt viel Code-Doppelung.
Dann hast du etwas falsch gemacht. :-) Wenn du per Hand von Assembler in C übersetzt, dann sieht man dem Code das oft an (für hinreichend geschulten Leser), einfach weil du die Vorteile und Strukturen von C dann doch nicht nutzt.
Die Sache mit den nicht trivialen Algos ist allerdings die, das wenn man als Bsp ne Sprache wie Logic/Prolog/Haskel usw. nimmt, man vllt Code schreibt der schön aussieht und "leicht" lesbar ist, aber wie der Compiler das dann umsetzt entzieht sich eigentlich fast allen Programmierern.
Je höher die Programmiersprache ist, desto eher musst du wissen, welche Prinzipien bei der Umsetzung verwendet werden, wenn du nicht ausschließlich an der Lösung des Problems interessiert bist. (In den meisten Fällen ist man aber genau das.)
Das nächste ist, das es schwierig ist einen Compiler richtig zu steuern, ihm also zu sagen, die Funktion ist wichtig, hier jetzt die und die Optimierung machen, die Funktion ist nicht so wichtig, da muss nicht so optimiert werden und die Funktion soll auf Größe optimiert werden.
Aha, und das kriegst du per Hand eleganter und effizienter hin? Ich behaupte, dass du in Assembler implizit erstmal alles auf Größe optimierst, weil es dann länger übersichtlich bleibt.
Gut dazu gibt es #pragma, aber ich bin mir nicht sicher ob das im Standard ist oder ob das ne gcc Erweiterung ist.
Compiler-Anweisungen sind compilerspezifisch.
Was mich auf jeden Fall an z.B. C stört, ist das ständige herumgecaste ;) Ich will nunmal auch vernünftig mit Pointern rechnen können!
Wenn du Pointer nicht assemblertypisch als "Zahl" betrachtest, sondern als "Datentyp Pointer", wird es schon viel einfacher... zumal du in vielen Sprachen (z.B. Visual Basic) ohnehin keine Pointer hast und da dann drumrumprogrammierst...
Gruß,
Svenska
-
Aha, und das kriegst du per Hand eleganter und effizienter hin? Ich behaupte, dass du in Assembler implizit erstmal alles auf Größe optimierst, weil es dann länger übersichtlich bleibt.
Vom Prinzip her ja und man verwendet keine "Compiler" spezifischen Sachen. Ich kann ja einfach die eine Funktion die ich schreibe auf Größe optimieren und eine andere auf Geschwindigkeit (z.B. durch Alignment, Loop-Unrooling usw.).
Assembler-Code ist ab einer gewissen Größe nicht mehr übersichtlich ;) Mit sowas muss man aber in jeder Sprache leben, sowas wie die perfekte Sprache ist leider noch nicht entwickelt worden :(
Wenn du Pointer nicht assemblertypisch als "Zahl" betrachtest, sondern als "Datentyp Pointer", wird es schon viel einfacher... zumal du in vielen Sprachen (z.B. Visual Basic) ohnehin keine Pointer hast und da dann drumrumprogrammierst...
Das ist übrigens auch so ein Vorteil (je nachdem wie man es sieht) von Assembler, ich brauche um nichts herum zu programmieren, ich mache es einfach!
Das Problem ist halt mit Pointer, das ich die oft einfach nur als Zahl brauche und dann wieder als Pointer usw.
Mein Code ist voll mit solchen Castings (hat nichts mit DSDS oder solchem Schmarn zu tun ;) ) und das sieht einfach nicht schön aus. Zumal man da wieder bei so einer Sache ist, wenn man wirklich schönen leserlichen Code schreibt, überlässt man halt die ganze Arbeit dem Compiler und der ist nunmal dumm!
-
zu den gotos in Assembler: Das ist wahrscheinlich die beste Performance"optimierung" die man machen kann, da wird sich die Branchprediction und die Pipeline freuen :-D
und zu Pointern:
#define adjust_pointer(p, T, offset) (T*)((uint8_t*)p + offset)
noch schöner (zu benutzen) gehts in C++ mit:
template<typename T>
T* adjust_pointer(T* p, size_t offset)
{
return reinterpret_cast<T*>(reinterpret_cast<uint8_t*>(p) + offset));
}
Ansonsten sollte man wohl zwischen funktionalen oder deklarativen und imperativen Sprachen unterscheiden. Das ich in Haskel keine Kontrolle über die Codegenerierung habe, ist irgendwie klar, aber auch eben nicht gewollt.
zu Optimierung: über __attribute__ kann man bei gcc teilweise Optimierungen ein/ausschalten (zumindest gibt "hot" und "cold")
edit: es gibt auch "optimize", siehe http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
zu #pragma: ist vollständig compilerspezifisch
-
Ich kann ja einfach die eine Funktion die ich schreibe auf Größe optimieren und eine andere auf Geschwindigkeit (z.B. durch Alignment, Loop-Unrooling usw.).
Tust du das auch oder kannst du es nur?
Das Problem ist halt mit Pointer, das ich die oft einfach nur als Zahl brauche und dann wieder als Pointer usw.
Mein Code ist voll mit solchen Castings (hat nichts mit DSDS oder solchem Schmarn zu tun ;) ) und das sieht einfach nicht schön aus.
Dann machst du grundsätzlich irgendwas falsch oder hast nicht sinnvoll abstrahiert.
Zumal man da wieder bei so einer Sache ist, wenn man wirklich schönen leserlichen Code schreibt, überlässt man halt die ganze Arbeit dem Compiler und der ist nunmal dumm!
Da widerspreche ich dir, möchte da aber auf vorhergehende Analysen verweisen und dies nicht ausdiskutieren. Moderne Compiler enthalten wahrscheinlich mehr Intelligenz als du glaubst. Außerdem haben sie mehr CPU-spezifisches Wissen als du.
Gruß,
Svenska
-
Man kann gcc sogar Profiling-Informationen (was z.B. statistische Informationen über Branches beinhaltet) geben, die dann in die Optimierung miteinfließen.
edit: Mich würde es übrigens wundern, wenn echt optimierter Assemblercode lesbar ist, da man zum Optimieren Instruktionen sehr wild reordnern müsste. Aber es optimiert sowieso keiner, insofern ist die Frage eher theoretischer Natur. :-D
-
Hallo,
@tev:Wenn Du speziell für den P4 optimieren willst dann solltest Du bedenken das es für diesen 2 verschiedene Typen an Chipsätzen gab. Einmal mit dem doofen und billigen Standard-DDR-SDRAM und einmal mit dem coolen und teuren RAMBUS-DRAM. Letzterer kann eine höhere Transferrate aber manchmal auch niedrigere Latenzen bieten (u.a. weil er mehr Pages/Lines offen halten kann). Gerade bei der extrem langen P4-Pipeline kann es von erheblicher Bedeutung sein ob die gewünschten Daten aus dem RAM schon da sind oder ob gewartet werden muss. Performance hängt von sehr viel mehr ab als nur von der CPU!
Den L4-Ansatz halte ich persönlich nicht für sehr zielführend weil da extrem viel per IPC kommuniziert werden muss. Ich würde eher versuchen die guten IPC-Konzepte des L4 mit einem vollwertigen Mikrokernel zu verbinden (das möchte ich zumindest versuchen).
Der P4 hat einen L1-Code-Cache der ungefähr 12 kBytes entspricht und das ist schon ziemlich wenig wenn Du wirklich versuchen möchtest das Dein Kernel mit einem so extrem kleinen Cache-Foot-Print aus kommt das er da weitestgehenst komplett rein passt (zumindest die permanent verwendeten Code-Teile) und noch genug für die Applikationen übrig bleibt.
Grüße
Erik
achja, ich wurde ja gebeten Teil zu nehmen:
.... Compiler und der ist nunmal dumm!
Genau das stimmt absolut nicht. Ich habe mir schon von einigen Compilern den Assembler-Code angesehen und muss sagen das da teilweise Tricks drin waren auf die ich nicht von alleine gekommen wäre. Nebst dessen das ein Compiler problemlos verschiedene Wege verfolgen kann um dann zum Schluss das beste Ergebnis zu benutzen. Die Kernfrage ist "Was ist der optimale Code?". Wenn damit die Ausführungsgeschwindigkeit gemeint ist wird bei Programmen ab einer gewissen Größe immer der Compiler gewinnen einfach weil er mehr Arbeitsspeicher zur Verfügung hat als das menschliche Gehirn. Klar könnte theoretisch der Mensch den besseren Code abliefern (der Compiler wurde ja auch von einem Menschen entwickelt) aber wenn man tausende Details beachten muss die auch noch sehr komplexe wechselseitige Abhängigkeiten haben dann verliert der Mensch irgendwann den Überblick, spätestens bei 10'000 (um einfach mal ne hohe Zahl zu nennen) Assemblerbefehlen ist Schluss das kann kein Mensch mehr im Kopf optimieren. Das nächste Problem ist der sogenannte Schmetterlingseffekt (http://de.wikipedia.org/wiki/Schmetterlingseffekt), da der Compiler den Assembler-Code bei jedem Durchlauf komplett neu erzeugt kann er auch bei jedem iterativen Programmierschritt den optimalen Code erzeugen wohingegen der menschliche Assemblerprogrammierer wohl kaum das gesamte Programm komplett umgestalten wird nur weil sich irgendwo ein Detail geändert hat das nun Auswirkungen auf die Optimierungsstrategie hat. Ein Beispiel sind da die Aufrufkonventionen die die Compiler (innerhalb einer Übersetzungseinheit und bei LTO auch über das gesamte Programm) nach Bedarf frei festlegen können. Wenn in einer Leaf-Funktion z.B. ein Algorithmus geändert wird der dann mit weniger/mehr Registern auskommt kann der Compiler entscheiden das die aufrufenden Funktionen mehr/weniger Register sichern müssen und das kann theoretisch Rückwirkungen bis hin zu main haben.
Ich betrachte mich als recht guten Assemblerprogrammierer, ich habe da über 15 Jahre Erfahrung und kann auf mehreren (recht unterschiedlichen CPU-Architekturen) in Assembler programmieren (wenn auch nicht auf allen gleich gut). Darüber hinaus habe ich auch einiges an Ahnung davon wie eine CPU funktioniert. Trotzdem würde ich niemals behaupten das mein Assembler-Code auch nur annähernd so gut ist wie der von einem guten Compiler der gut programmierten Hochspachen-Code compiliert.
Wenn hier schon verglichen werden soll dann sollten aber der Assembler-Code und der Hochsprachen-Code (und auch der Compiler) von einem jeweils guten Programmierer stammen. Ob der Vergleich dann bei einer einigermaßen großen Problemstellung (also etwas das mindestens 100'000 Zeilen C-Code entspricht) auch nur annähernd für den Assemblerprogrammierer ausgeht wage ich sehr zu bezweifeln, mal ganz davon abgesehen das der Assemblerprogrammierer vielleicht gar nicht lange genug lebt um überhaupt fertig zu werden.
Mich würde es übrigens wundern, wenn echt optimierter Assemblercode lesbar ist, da man zum Optimieren Instruktionen sehr wild reordnern müsste. Aber es optimiert sowieso keiner, insofern ist die Frage eher theoretischer Natur.
Zu der Zeit als ich versucht habe an Grafik-Demos mit zu programmieren (was aber nicht so meine Stärke war und ich mich dann lieber auf den PM-Unterbau konzentriert habe) haben wir die verschiedenen Datenflüsse durch den Assembler-Code versucht mit unterschiedlichen Einrückungen der Befehle auseinander zu halten und das Ergebnis war auch tatsächlich einigermaßen lesbar aber trotzdem nicht wirklich wartbar (wir haben dann mehrmals nur die Reihenfolge der Befehle einer ganzen Funktion umarrangiert nur weil sich irgendwo ein kleines Detail geändert hat). Mit einem heutigen Compiler verglichen war unser Code sicher trotzdem noch lange nicht optimal und wir haben auch nur kleine Teile der Demos in Assembler programmiert.
Das war mein Senf zum aktuellen Flame-War.
PS.: Flame-Wars sind voll Moppelkotze!!
-
Zu dem Statement, dass Compiler dumm sind, habt ihr mich leider falsch verstanden.
Was ich damit meine ist, das dem Compiler Wissen fehlt das ich als Programmierer haben. Bestes Bsp. sind If-Verzeigungen. Woher soll der Compiler wissen welche Verzweigung die wahrscheinlichere ist, es sei denn ich sage es ihm (was ja GCC spezifisch auch geht).
Und ein anderer Punkt ist, es wird noch immer in Assembler optimiert, wenn auch nur kleine sehr wichtige Stellen, aber wenn ein Mensch nie so gut wie ein Compiler optimieren könnte, wieso ist das dann immernoch der Fall und funktioniert auch?
Das nächste ist dann leserlicher Code, ich erinnere mich da an ein paar Zahlenspiele um eine gewisse Optimierung (war was um fließkomma Zahlen mit hilfe von Integerzahlen zu berechnen oder so) die man ohne Hintergrundwissen und Kommentare nie verstanden hätte. Auf sowas kommt auch kein Compiler und da sind wir wieder dabei das ein Compiler dumm ist.
Edit::
@bluecode
Du willst also das gecaste einfach hinter nem Macro oder ner Funktion verstecken, aber das eigentliche Problem ist damit nicht weg.
Mal ein blödes Bsp.:
struct foo_t *bar= startWert;
for(int x= 0; x < schoenerWert; x++) {
//mache was mit den Daten der Struktur
...
bar= (struct foo_t *)((uint32t)bar + bar->size));
}
Ist nur mal nen einfaches Bsp. Ich habe noch anderen Code wo noch wilder gecastet wird und auch mit dem Pointer gerechnet wird.
-
Du willst also das gecaste einfach hinter nem Macro oder ner Funktion verstecken, aber das eigentliche Problem ist damit nicht weg.
Wenn du jetzt noch erklären würdest wo das Problem beim Casten ist? Außer das man damit Typisierung umgeht, die man in Assembler erst gar nicht hat, sehe ich keines. Der Nachteil gegenüber Assembler ist also ≤ 0.
[edit]
Das nächste ist dann leserlicher Code, ich erinnere mich da an ein paar Zahlenspiele um eine gewisse Optimierung (war was um fließkomma Zahlen mit hilfe von Integerzahlen zu berechnen oder so) die man ohne Hintergrundwissen und Kommentare nie verstanden hätte. Auf sowas kommt auch kein Compiler und da sind wir wieder dabei das ein Compiler dumm ist.
Ich hoffe ich habe dich jetzt richtig verstanden. Mein beispiel ist jetzt zwar Ganzzahlig, aber ich denke das ist aussagekräftig genug:
rdx := rax / 10sieht bei gcc so aus:
movabsq $-3689348814741910323, %rdx
mulq %rdx
shrq $3, %rdxdas sind [?]+5+1Ticks(laut AMD)
und du willst mir jetzt hoffentlich nicht erzählen, das du dafür kein 'div' benuzt hättest, das braucht 16Ticks
-
FlashBurn: genau für den Code war das Makro/die Funktion gedacht.
Wahrscheinlich emfindet FlashBurn Typisierung allgemein als lästig. Ich finde es eigentlich eher hilfreich, wenn der Compiler meckert weil ich (was in der Mehrzahl der Fälle auch stimmt) Mist gebaut habe. Abgesehen davon finde ich es gut, wenn ich (manche) Casts (die Ausnahme wäre zB obiges Makro, das relativ ungefährlich ist) sehe, denn es macht explizit das hier irgendetwas "Böses" passiert.
-
Hallo,
Was ich damit meine ist, das dem Compiler Wissen fehlt das ich als Programmierer haben. Bestes Bsp. sind If-Verzeigungen. Woher soll der Compiler wissen welche Verzweigung die wahrscheinlichere ist, es sei denn ich sage es ihm (was ja GCC spezifisch auch geht).
Wenn Du erwartest das der Assemblerprogrammierer seine Jumps so optimiert das für den wahrscheinlichen Ausführungspfad möglichst wenige Sprünge entstehen aber der C-Programmierer keine Vorgaben für den Compiler macht (obwohl er ja auch weiß welcher der wahrscheinliche Ausführungspfad ist) dann vergleichst Du Äpfel mit Birnen. Klar weiß der Compiler nicht wie Dein Programm funktioniert, genauso wenig wie der Assembler und der Linker, aber beide Programmierer wissen das und im Endeffekt kann der Compiler mit Hilfe dieser Information wohl besseren Code erzeugen als der menschliche Assembler-Programmierer.
Und ein anderer Punkt ist, es wird noch immer in Assembler optimiert, wenn auch nur kleine sehr wichtige Stellen, aber wenn ein Mensch nie so gut wie ein Compiler optimieren könnte, wieso ist das dann immernoch der Fall und funktioniert auch?
Da geht es oft um spezielle Fälle oder um Situationen wo der Compiler eine neue Befehlssatzerweiterung der CPU noch nicht kennt.
ich erinnere mich da an ein paar Zahlenspiele um eine gewisse Optimierung (war was um fließkomma Zahlen mit hilfe von Integerzahlen zu berechnen oder so) .... Auf sowas kommt auch kein Compiler und da sind wir wieder dabei das ein Compiler dumm ist.
Aber der menschliche Programmierer kommt darauf das man manchmal auch Floating-Point-Operationen mit Hilfe von Integer-Befehlen erledigen kann und wenn der Assembler-Programmierer das darf dann darf das auch der C-Programmierer tun (in C gehen solche Tricks schließlich auch). Wieder versuchst Du die Unfähigkeit eines offenbar schlechten C-Programmierers dem Compiler anzulasten. Wenn wir schon vergleichen wollen dann bitte auch unter wirklich gleichen Voraussetzungen, also auch exakt gleiche Algorithmen usw.
Grüße
Erik
-
Was ich damit meine ist, das dem Compiler Wissen fehlt das ich als Programmierer haben. Bestes Bsp. sind If-Verzeigungen. Woher soll der Compiler wissen welche Verzweigung die wahrscheinlichere ist, es sei denn ich sage es ihm (was ja GCC spezifisch auch geht).
Wenn Du erwartest das der Assemblerprogrammierer seine Jumps so optimiert das für den wahrscheinlichen Ausführungspfad möglichst wenige Sprünge entstehen aber der C-Programmierer keine Vorgaben für den Compiler macht (obwohl er ja auch weiß welcher der wahrscheinliche Ausführungspfad ist) dann vergleichst Du Äpfel mit Birnen. Klar weiß der Compiler nicht wie Dein Programm funktioniert, genauso wenig wie der Assembler und der Linker, aber beide Programmierer wissen das und im Endeffekt kann der Compiler mit Hilfe dieser Information wohl besseren Code erzeugen als der menschliche Assembler-Programmierer.
Wie oben erwähnt, man kann dem Compiler Prolfing-Informationen übergeben, damit kann er den/die häufigsten Pfade optimieren. Das ist sogar noch viel effektiver, da es reale Informationen sind und nicht irgendwas vom Programmierer erdachtes.
-
Hallo,
Wie oben erwähnt, man kann dem Compiler Prolfing-Informationen übergeben, damit kann er den/die häufigsten Pfade optimieren. Das ist sogar noch viel effektiver, da es reale Informationen sind und nicht irgendwas vom Programmierer erdachtes.
Das kommt noch dazu. Es ging mir nur in erster Linie darum das es kein fairer Vergleich ist wenn der Assembler-Programmierer vorhandene Informationen nutzt und der C-Programmierer nicht. Das der Compiler das eigentlich sogar noch besser kann als der Mensch ist nur noch ein weiteres Argument gegen die Behauptung das der Compiler dumm sei.
Grüße
Erik
-
FlashBurn meint folgenden Code:
float SquareRootFloat(float number) {
long i;
float x, y;
const float f = 1.5F;
x = number * 0.5F;
y = number;
i = * ( long * ) &y;
i = 0x5f3759df - ( i >> 1 );
y = * ( float * ) &i;
y = y * ( f - ( x * y * y ) );
y = y * ( f - ( x * y * y ) );
return number * y;
}
Man beachte dies hier zur Erklärung: http://www.codemaestro.com/reviews/9 (http://www.codemaestro.com/reviews/9).
Dazu drei Hinweise:
(a) Handelt es sich hier um C. Ob du dies nun in Assembler oder in C programmierst, ist unerheblich, da die Idee an sich auf Genialität basiert. Im Gegenteil, in Assembler wäre das noch unverständlicher. :-)
(b) Dieser Algorithmus berechnet die Quadratwurzel eines Float mit der Integereinheit der CPU (und stammt u.a. aus der Quake III-Engine). Grundgedanke ist das Näherungsverfahren von Newton, bei dem man iterativ aus einem gegebenen Schätzwert einen besseren Schätzwert erzeugt. Der Trick hierbei ist der gegebene Schätzwert, der die Anzahl der Iterationen hierbei auf eins reduziert.
(c) Laut Aussage auf der verlinkten Webseite ist dieses Codefragment - je nach CPU - bis zu viermal schneller als "1.0/sqrt(x)", welches üblicherweise mit der Gleitkommaeinheit berechnet wird. Zur Zeit von Quake III waren noch CPUs von Cyrix weitverbreitet, die eine sehr schnelle Integer- aber eine sehr langsame Gleitkommaeinheit hatten. Daher war das wichtig.
Gruß,
Svenska
-
Gut auf was ich hinaus will ist, dass wenn man sagt, ein Mensch kann nie optimalen Code schreiben, aber der Compiler kann es, wie willst du dann als Mensch wissen das der Code vom Compiler optimal ist? Entweder du weißt es und damit hättest du ihn genauso schreiben können oder du weißt es nicht und kannst es dann auch nicht behaupten.
Desweiteren geht ihr hier alle vom GCC aus, was ist mit anderen Compilern die es gibt und anderen Sprachen? Wenn der GCC den optimalen Code erzeugt wieso ist dann der Intel Compiler meistens noch ein bißchen schneller?
Ich kenne genügend Programmierer die in der Lage wäre wirklich sehr schnellen Code in Assembler zu schreiben, aber da sie sich ja sagen der Compiler produziert ja optimalen Code machen sie sich über ihren Code weniger Gedanken und überlassen die ganze Arbeit dem Compiler. Aber woher will man wissen das dieser auch seine Arbeit so verrichtet wie man sich das denkt?
Was die Vorgaben an den Compiler betrifft, da ist halt das Problem das nicht jeder Compiler das unterstützt (??) und du damit auch vom Sprachstandard abweichst.
@Svenska
Jap, das war der Code.
Der Punkt ist doch halt der, wer heute programmieren lernt, bekommt von allen Seiten eingetrichtert der Compiler erzeugt grundsätzlich optimalen Code und du könntest es eh nicht besser. Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?
Was aber an einer Hochsprache und damit auch an einem Compiler wesentlich besser ist als bei Assembler ist, dass man seinen Code Jahre später für eine neuere CPU übersetzen kann und der Compiler dann (hoffentlich) schnelleren Code erzeugt.
-
*sigh* nochmal: nicht optimal, sondern optimaler als es den meisten Menschen in sinnvollen Zeitschranken und unter minimaler Beachtung normaler Softwareentwicklungskriterien (Wartbarkeit, iterative Entwicklung) je möglich wäre.
edit: Optimale Codegenerierung dürfte sehr wahrscheinlich sowieso nicht (algorithmisch) machbar sein, ich denke das geht der armen Turingmaschine dann doch zu weit.
Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?
Exakt darüber - die Algorithmik und die Datenstrukturen - versuchen wir uns Gedanken zu machen und da verwenden auch C Programmierer wenn es nötig ist (d.h. es wurde vorher gemessen, dass die Performance nicht toll ist) Assembler. Das ist ein Job der komplementär zu dem des Compilers ist und ich würde niemals deswegen den Compiler wegwerfen wollen und alles selbst machen. Es wurde glaube ich auch schon gesagt, aber einen etwas schwierigeren Algorithmus bzw. eine etwas schwierigere Datenstruktur würde ich nicht in Assembler implementieren wollen, die sind schon so schwer genug zu verstehen.
Die wichtigste Frage ist aber: Wo lohnt es sich was selbst zu optimieren und wo nicht? Bei Matrixoperationen und einem 3D-Spiel lohnt es sich sicherlich das über SSE zu machen und das kann der Compiler nur bedingt automatisch machen.
-
Hallo,
Gut auf was ich hinaus will ist, dass wenn man sagt, ein Mensch kann nie optimalen Code schreiben, aber der Compiler kann es, wie willst du dann als Mensch wissen das der Code vom Compiler optimal ist? Entweder du weißt es und damit hättest du ihn genauso schreiben können oder du weißt es nicht und kannst es dann auch nicht behaupten.
Die Ausführungsgeschwindigkeit eines Programms kann man messen und dazu muss man noch nicht einmal wissen was Assembler überhaupt ist. Damit kann man zwar nicht feststellen ob der Code wirklich optimal ist (also das absolute Maximum an Performance erreicht) aber man kann damit recht gut bestimmen welche Umsetzung besser ist und nur darum geht es doch hier.
Desweiteren geht ihr hier alle vom GCC aus, was ist mit anderen Compilern die es gibt und anderen Sprachen? Wenn der GCC den optimalen Code erzeugt wieso ist dann der Intel Compiler meistens noch ein bißchen schneller?
Klar ist der Intel-Compiler oft noch einen Tick besser als der GCC aber was sagt das über den Vergleich von "Compiler vs. Mensch" aus? Der Mensch ist bei größeren Programmen weder dem GCC noch dem Intel-Compiler gewachsen. So what?
Ich kenne genügend Programmierer die in der Lage wäre wirklich sehr schnellen Code in Assembler zu schreiben, aber da sie sich ja sagen der Compiler produziert ja optimalen Code machen sie sich über ihren Code weniger Gedanken und überlassen die ganze Arbeit dem Compiler.
Genau für diese Drecksarbeit gibt es ja den Compiler, also warum soll ich dem das dann nicht auch überlassen?
Aber woher will man wissen das dieser auch seine Arbeit so verrichtet wie man sich das denkt?
Erfahrung und Vertrauen in die Fähigkeiten der menschlichen Compiler-Programmierer die ihr Werk sicherlich auch mal mit möglichst vielen verschiedenen Beispiel-Codes testen.
Was die Vorgaben an den Compiler betrifft, da ist halt das Problem das nicht jeder Compiler das unterstützt (??) und du damit auch vom Sprachstandard abweichst.
Und was sagt das über den Vergleich von "Compiler vs. Mensch" aus? Nichts! Du kannst nicht einfach sagen da es ja auch schlechte Compiler gibt ist der Mensch der bessere Code-Generator. Du versuchst die ganze Zeit Äpfel mit Birnen zu vergleichen! Wenn Du von einem guten und erfahrenen Assembler-Programmierer aus gehst dann musst Du für die andere Seite auch einen guten und aktuellen Compiler (zusammen mit einem fähigen Hochsprachen-Programmierer) annehmen.
wer heute programmieren lernt, bekommt von allen Seiten eingetrichtert der Compiler erzeugt grundsätzlich optimalen Code und du könntest es eh nicht besser.
Was ja auch auf über 99% aller Programmierer absolut zutrifft. Nebst dessen das nur weil man etwas theoretisch besser kann heißt das nicht das man das auch tatsächlich in die Praxis umsetzen kann, gerade bei großen Programmen (die iterativ entwickelt werden) ist das Erzeugen von optimalen Assembler-Code per Hand in endlicher Zeit absolut unmöglich.
Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?
Der gezeigte Trick hat aber auch nichts mit der verwendeten Programmiersprache zu tun sondern ist algorithmischer Natur.
@FlashBurn:
Diese Behauptung das der Mensch den besseren Code generieren kann ist rein akademischer Natur weil es einfach in der Praxis nicht umsetzbar ist! Die maximale Lebenserwartung eines Menschen ist nun mal beschränkt (und ich hoffe das bleibt auch für immer so).
Grüße
Erik
-
nicht optimal, sondern optimaler als es den meisten Menschen in sinnvollen Zeitschranken und unter minimaler Beachtung normaler Softwareentwicklungskriterien (Wartbarkeit, iterative Entwicklung) je möglich wäre.
Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben ;) Dass das länger dauert, Assembler nicht wirklich wartbar oder portierbar ist, dagegen sage ich auch nichts. Es ist aber möglich und genau diese Möglichkeit wird doch von den meisten in Frage gestellt.
Ich sage auch nicht das man Compiler wegwerfen sollte, auf keinen Fall, da wird man ja gar nicht mehr fertig ;) Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.
Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!
@erik
Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.
Wenn ich mir einen bestimmten Zeitpunkt aussuche, dann kann ein Mensch ohne großen Aufwand besseren Code als ein Compiler erzeugen. Nämlich dann wenn es noch keinen Compiler für eine bestimmte Architektur gibt oder wenn der Compiler noch nicht richtig angepasst ist. Das gilt auch für moderne Compiler.
-
Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.
Von wem wird das grundsätzlich ausgeschlossen (ohne Randbedingungen)? Ich würde ja vermuten, dass das niemand war oder das derjenig implizit "realistische" Randbedinungen gewählt hat.
-
Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben ;) Dass das länger dauert, Assembler nicht wirklich wartbar oder portierbar ist, dagegen sage ich auch nichts. Es ist aber möglich und genau diese Möglichkeit wird doch von den meisten in Frage gestellt.
Also zumindest, dass man von Hand gleich guten Code schreiben kann wie der Compiler, ist trivialerweise wahr: Ich kann mir den Compilercode anschauen und mit genügend Zeit und Konzentration (Fehler sollten lieber nicht passieren ;)) kann ich den Algorithmus auch von Hand ausführen. Toll als theoretischer Beweis, aber ich nehme an, jeder wird mir zustimmen, dass das in der Praxis Blödsinn ist.
Ich sage auch nicht das man Compiler wegwerfen sollte, auf keinen Fall, da wird man ja gar nicht mehr fertig ;) Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.
Richtig, aber "man" ist in dieser Fall nicht jeder einzelne, der Hochsprachen-Code schreibt, sondern die Programmierer des Compilers. Die haben hoffentlich genug Arbeit reingesteckt und den Compiler gut genug gemacht, dass ich es mir sparen kann, das Rad neu zu erfinden. Die Compilerleute arbeiten auch eng mit den Prozessorherstellern zusammen (oder arbeiten sogar direkt für sie), so dass ihnen die genauen Details sehr wahrscheinlich besser bewusst sind als mir. Und damit kann der Compiler dann besser optimieren als ich es ohne dieses Wissen kann.
-
Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben ;)
Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.
Ich kann auch /dev/urandom (oder die Ausgabe von 10000 Affen an Schreibmaschinen) in eine Datei pipen, versuchen, die zu assemblieren und das Ergebnis ausführen, wenn der Dateiinhalt syntaktisch in Ordnung war. Dann teste ich, ob er auch semantisch in Ordnung ist. Das mache ich dann so oft, bis ich ein paar korrekte Ergebnisse zusammen habe, die schneller als der compilergenerierte Code sind und suche mir dann davon das schnellste aus.
Kann man auch machen, ist theoretisch möglich. Dauert nur halt ein kleines bisschen. Wenn man aber ∞ Affen nimmt, wäre das beste Ergebnis sogar sofort da. :lol:
Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!
Du weißt schon, dass ein menschliches Gehirn (meiner Annahme nach das Ding, was wir zum Assemblercode schreiben nutzen) aus Synapsen besteht, die einzeln ohne Probleme von einem Computer simuliert werden können? Wenn man einen genügend leistungsfähigen Computer hätte, könnte der mal nebenbei ein ganzes menschliches Gehirn simulieren. Da könnte man dann auch einen intelligenten Compiler drauf laufen lassen.
Das menschliche Gehirn ist also auch nur so weit intelligent, wie es „programmiert“ worden ist. imho.
-
Hallo,
Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.
Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!
Der Hinweis mit den "Profiling-Informationen" kam ja schon! Was willst Du denn da noch? Wirklich intelligent ist der Compiler natürlich nicht aber es stehen ihm eine ganze Menge sehr guter Werkzeuge zur Verfügung die Du als Mensch nicht so ohne weiteres hast.
Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann.
Das habe ich auch nie behauptet! Ich versuche Dir nur klar zu machen das es die Realität eben nicht ohne Nebenbedingungen gibt. Zu diesen Nebenbedingen gehört die begrenzte Lebenserwartung des Menschen genauso wie Kunden/Auftraggeber die 10 Minuten vor dem Liefertermin noch zu Dir kommen und Sätze aussprechen die mit "Ich bräuchte da aber noch ...." oder "Da kann man doch bestimmt noch ...." anfangen. Solange Du diese Nebenbedingen komplett ausschließen kannst ist es sicher theoretisch möglich das ein Mensch besseren Code abliefert als ein Compiler aber in der Realität ist das eben nicht so. Da wir aber nun mal alle in der Realität leben (zumindest vermute ich das von uns allen) müssen wir eben auch die zugehörigen Nebenbedingen mit einkalkulieren und so ergibt sich eben das der Mensch keine Chance gegen einen guten Compiler hat.
Wenn ich mir einen bestimmten Zeitpunkt aussuche, dann kann ein Mensch ohne großen Aufwand besseren Code als ein Compiler erzeugen. Nämlich dann wenn es noch keinen Compiler für eine bestimmte Architektur gibt oder wenn der Compiler noch nicht richtig angepasst ist. Das gilt auch für moderne Compiler.
Und wieder versuchst Du spezielle Bedingunen zu schaffen die dem Menschen einen Vorteil geben. Klar kann ich für meine CPU derzeit den besten Code abliefern einfach weil es noch keinen Compiler gibt aber das ist hoffentlich kein Dauerzustand. Nebst dessen das ich es doof finde das Du versuchst Bedingungen auszuschließen die die Realität einfach unumstößlich vorgibt aber selber versuchst mit untypischen Annahmen doch noch die Compiler schlecht zu machen. Wenn Du einen guten menschlichen Assembler-Programmierer aufs Feld führen möchtest dann musst Du auch einen guten modernen Compiler als Gegner akzeptieren! Der Ausgang eines solchen fairen Duells dürfte wohl ziemlich eindeutig zu Gunsten des Compilers ausfallen.
Grüße
Erik
-
@XanClic
Intelligenz erfordert doch aber auch die Fähigkeit zu lernen oder? Und dazu sind Compiler noch nicht fähig, man muss sie programmieren, aber von alleine schaffen sie es noch nicht.
Man würde also unendlich lange für ein bestimmtes komplexes Problem in Assembler brauchen, das man in endlicher Zeit mit Hilfe eines Compilers/Hochsprache lösen kann?
@taljeth
Du willst das Rad also nicht neu erfinden. Wieso erfindest du dann das Rad=OS neu? Es gibt doch schon genügend Räder=OS.
Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.
Um es mal auf einen anderen Fall zu übertragen. Man nehme sich 2 Sportler und die laufen gegeneinander 100m, aber es hat nicht der gewonnen der weniger Zeit benötigt hat, sondern der der das auch noch mit weniger Training geschafft hat.
Das wäre so in etwa das gleiche, ein Assembler-Programmierer kann also nicht gewinnen, weil er immer länger brauchen wird als z.B. ein C-Programmierer.
Desweiteren geht ihr auch von sehr hardwarenahen Sprachen aus. Denn wenn ich das mal ummünze, heißt es also auch ein Assembler-Programmierer kann keinen schnelleren Code schreiben als ein Java-Compiler (das Java nunmal in einer VM läuft ist ja egal, es geht um das Ergebnis).
@erik
Du schaffst doch auch gute Nebenbedingungen für einen Compiler, sprich du baust dir deine Realität auch so wie du sie brauchst!
Was den Kunden und Änderungen kurz vor Schluss betrifft. Dafür gibt es ein Pflichtenheft und was da nicht drinsteht muss auch für die Erfüllung des Auftrages zu einem bestimmten Termin nicht gemacht werden. Wenn der Auftraggeber dann noch was will, muss halt neu verhandelt werden, inklusiver eines neuen Termines.
Aber zurück zum Thema, wer als Hobby ein OS schreibt, hat keine Termine die eingehalten werden müssen. Angefangen hat doch die Diskussion dadurch:
Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest
Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.
Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.
-
Du willst das Rad also nicht neu erfinden. Wieso erfindest du dann das Rad=OS neu? Es gibt doch schon genügend Räder=OS.
Es reicht ja, ein Rad neu zu erfinden, oder? ;)
Ich schreibe auch nicht zusätzlich noch einen Bootloader, Firmware, baue mir keine passende CPU und sonstige Hardware, bau mir keinen eigenen Reaktor, um das Ding zu betreiben...
Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.
Das ist ein Nullargument. Es gibt auch schlechte Assemblerprogrammierer. Guter Compiler gegen guten Programmierer, schlechter Compiler gegen schlechten Programmierer, schon passt die Welt wieder.
Desweiteren geht ihr auch von sehr hardwarenahen Sprachen aus. Denn wenn ich das mal ummünze, heißt es also auch ein Assembler-Programmierer kann keinen schnelleren Code schreiben als ein Java-Compiler (das Java nunmal in einer VM läuft ist ja egal, es geht um das Ergebnis).
Ich erhalte meine Aussage auch für Java aufrecht.
Wo du immer das "Programmierer kann keinen schnelleren Code schreiben" hernimmst, weiß ich nicht. Das ist weder meine Aussage noch die irgendeines anderen in diesem Thread. Anderen blödsinnige Aussagen unterzuschieben ist eine typische Trolltechnik.
Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.
Hat das irgendjemand bestritten? Es gibt Fälle, in denen der Einsatz von Assembler sinnvoll ist (Entwicklungsgeschwindigkeit ist dabei auch nur das eine, Fehleranfälligkeit nochmal eine ganz andere Baustelle), aber für komplette Großprojekte ist das eher nicht der Fall.
-
Intelligenz erfordert doch aber auch die Fähigkeit zu lernen oder? Und dazu sind Compiler noch nicht fähig, man muss sie programmieren, aber von alleine schaffen sie es noch nicht.
Dass sie es jetzt können, habe ich ja auch nicht gesagt. Ich wollte nur zeigen, dass letzten Endes auch das menschliche Gehirn nicht viel mehr als ein Computer ist, wenn auch sehr viel komplexer als unsere heutigen Rechner.
Aber um auf das Lernen einzugehen: Ist es denn wichtig, dass Compiler von sich aus lernen können? Macht sie das besser? Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.
Man würde also unendlich lange für ein bestimmtes komplexes Problem in Assembler brauchen, das man in endlicher Zeit mit Hilfe eines Compilers/Hochsprache lösen kann?
Nein. Ich wollte nur zeigen, dass die Aussage „Es ist theoretisch möglich“ nicht viel Sinn in sich trägt, da ich dann nicht mal einen Menschen zum Programmieren brauche.
Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.
Die nehme ich dann aber definitiv nicht.
Du kannst keinen guten Assemblerprogrammierer mit einem schlechten Compiler vergleichen. Geht nicht. :roll:
Um es mal auf einen anderen Fall zu übertragen. Man nehme sich 2 Sportler und die laufen gegeneinander 100m, aber es hat nicht der gewonnen der weniger Zeit benötigt hat, sondern der der das auch noch mit weniger Training geschafft hat.
Nicht ganz richtig. Es hat schon der gewonnen, der weniger Zeit benötigt hat, aber: Wenn der Zeitunterschied marginal (0,1 s), aber der der Trainingsunterschied gewaltig (drei Monate gegen fünf Jahre) ist, sollte sich der Gewinner mal fragen, ob es das wirklich wert war.
Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Klar. Das hat erik doch auch schon geschrieben. Und? Wer von uns, der nicht gerade seine eigene Architektur entwickelt, schreibt sein OS für eine nicht von GCC/Binutils unterstützte Architektur?
-
@FlashBurn
WT*?
Natürlich gibt es auch schlechte Compiler. Aber es gibt auch noch schlechtere Programmierer. Wir reden hier von modernen Compilern. Und zwei gleich guten Programmierern. Und das Java langsam ist weil es in einer VM Ausgeführt wird ist nun auch schon Überholt.
Und nochmal, es beschreitet hier niemand das der Mensch theoretisch in der lange ist den, den Perfekten Code(so fern er denn existiert) zu schreiben. Und auch nicht das Spezialfälle gibt in den das auch Praktisch umsetzbar ist.
Und es geht hier ja um die Entwicklung eines Kernels, nicht um ein strlen oder eine Matrixmultiplikation.
-
@XanClic
Bei dem Vergleich mit den 100m Lauf ist aber 0,1s schon gewaltig ;) Und auf nem Computer kommt es halt drauf an wie oft der Code ausgeführt wird (auch Kleinvieh macht mist).
Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.
Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".
Ansonsten baut sich jeder von uns (das schließt mich mit ein) seine Randbedingungen so wie er sie gerade braucht ;)
@taljeth
Das mit dem Troll geht jetzt dann aber doch etwas zu weit, ich werde doch auch nicht gleich persönlich ;) Zumal ich ja geschrieben habe, wo soetwas gesagt wurde!
Was Assembler als Sprache betrifft, ist es durchaus gängige Meinung, das man sie nicht mehr benötigt und das es keinen Sinn macht in ihr zu programmieren. Alle hier sollten wissen das es Dinge gibt, die nur in Assembler gelöst werden können und das es immer Fälle geben wird, wo man Assembler benötigt.
@MNemo
Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können ;)
@all
Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?
-
Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können ;)
Nur das 'strlen' nicht auch irgendwo ein OS hat. Sprich nur weil du eins besser hin bekommst als ein Compiler, heißt das nicht gleich das das andere auch besser hin bekommst.
[edit]Wenn es nur darum ginge das tev sein strlen in assembler programmiert weil der das besser Optimieren kann als ein Compiler hätte auch keiner was dagegen gesagt[/edit]
Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?
Sicher. Nur das sich Svenska, mit dem ersten Satz nicht auf irgend welche mini-proceduren bezieht, sonder in dem Kontext wohl eher auf den Gesamten Kernel, sollte eigentlich klar sein.
Der Konjunktiv ist wohl unglücklich gewählt, besser wäre "können wirst", um deutlicher zu machen das er sich auf die Praxis bezieht nicht auf die Theorie.
Insofern widerspricht sich das nicht mit Unseren aussagen.
-
Sprich nur weil du eins besser hin bekommst als ein Compiler, heißt das nicht gleich das das andere auch besser hin bekommst.
Naja, wir reden ja auch von einem konkreten Problem und nicht das ich (also irgendjemand) alle Probleme lösen könnte und das auch noch besser als der Compiler.
Der Konjunktiv ist wohl unglücklich gewählt, besser wäre "können wirst", um deutlicher zu machen das er sich auf die Praxis bezieht nicht auf die Theorie.
Ich kenne tev jetzt nicht, aber wer kann dir garantieren das er es nicht doch hinbekommt. Sowas wie 100% Sicherheit gibt es halt nicht, niemand kann die Zukunft voraussagen.
Ich weiß aus eigener Erfahrung das solche "du schaffst das eh nie" Aussagen einfach falsch sind.
-
Bei dem Vergleich mit den 100m Lauf ist aber 0,1s schon gewaltig ;)
Tja. Wenn du fünf Jahre deines Lebens vergeuden möchtest, von mir aus. :wink:
Und auf nem Computer kommt es halt drauf an wie oft der Code ausgeführt wird (auch Kleinvieh macht mist).
Es geht hier eben nicht um die Frage, ob ich einen C-Kernel verbessern kann, wenn ich an einigen Stellen handoptimierten Assemblercode einfüge. Es wurde oft genug gesagt, dass das auf jeden Fall so ist. Wie MNemo schreibt, es geht darum, ob es sinnvoll ist, den ganzen Kernel in Assembler zu schreiben.
Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.
Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".
Ich weiß zwar nicht genau, was du damit meinst, aber ich würde dem zustimmen. Mir geht es ziemlich am Hinterteil vorbei, wer den Compiler wie geschrieben hat. Das Ergebnis zählt, und dieses ist gut.
Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können ;)
Was er im Allgemeinen sogar tut. Und nochmal: Es geht nicht darum, dass der Compiler immer den perfekten Code erzeugt. Es ist nur eine Frage vom Verhältnis von Aufwand zu Nutzen. Von fünf Jahren gegen 0,1 Sekunden.
Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?
Wenn du die Aussage von Svenska meinst: Ja, und ich stimme ihr sogar zu. Dennoch würde ich das so nie als Argument verwenden und auch Svenska hat das imho eher wieder zurückgenommen.
Ich fasse mal meine Meinung zusammen: Ein Compiler erzeugt selten perfekten Code. Wie gut der Code ist, den ein Mensch schreibt, das hängt von seinen Fähigkeiten ab, von der zur Verfügung stehenden Zeit, etc. pp.. Im Allgemeinen brauche ich für eine Optimierung des Codes hin zu einer Stufe, die compileroptimiertem würdig ist, ein Vielfaches der Zeit, die ich für das Schreiben des Codes in der Hochsprache benötige, abgesehen davon, dass ich persönlich eh länger dafür brauche, überhaupt Assemblercode zu schreiben als den Hochsprachencode (schon allein, weil es normalerweise mehr Zeichen sind, die man zu tippen hat).
Eine weitere Optimierung dauert dann nochmal so lange. Insgesamt ist es deshalb für den größten Teil eines Großprojektes sinnvoll, ihn in einer Hochsprache zu schreiben. Potenziert sich der Nutzen von Handoptimierung hingegen erheblich (extrem häufig durchlaufene Funktionen, etc.), so ist es wiederum für einzelne Teile sinnvoll, sie von Hand zu optimieren – wenn das Ergebnis besser als das des Compilers ist.
-
Ich weiß aus eigener Erfahrung das solche "du schaffst das eh nie" Aussagen einfach falsch sind.
Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.
-
Hallo,
Du schaffst doch auch gute Nebenbedingungen für einen Compiler, sprich du baust dir deine Realität auch so wie du sie brauchst!
Wo hab ich das getan? Beweise!
Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!
Aber zurück zum Thema, wer als Hobby ein OS schreibt, hat keine Termine die eingehalten werden müssen.
Also spätestens Dein Todestag ist ein Termin den auch Du einhalten musst (ich hoffe bis dahin ist noch viel Zeit).
Wieso kommen eigentlich immer wieder Leute auf die Idee das bei Hobby-Projekten keine zeitliche Beschränkung existiert? Auch ich habe ein RL und auch meine Lebenszeit ist begrenzt und kostbar so das ich auch bei Hobby-Projekten immer überlegen muss ob ich das wirklich machen will.
Angefangen hat doch die Diskussion dadurch:Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest
Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.
Eine mit hoher Wahrscheinlichkeit wahre Aussage von Svenska, ohne jetzt tev schlecht machen zu wollen. Die Wahrscheinlichkeit das tev sich mit dem P4 und der ganzen Plattform drum herum auch nur halb so gut auskennt wie die Leute die den GCC entwickelt haben ist recht gering wenn auch nicht ganz 0. Klar ist es theoretisch Möglich das tev diesen Wissensrückstand mehr als nur aufholt aber wie viel Zeit müsste tev dafür investieren und wird er das als lohnend betrachten? Vielleicht schafft es tev ja tatsächlich mal besseren Code für einen kompletten Kernel zu erzeugen als der GCC das kann aber reicht dafür überhaupt sein restliches Leben aus?
So lange man die realitätsgebundenen Randbedingungen einhält (und dazu gehört vor allem das man nicht unbegrenzt viel Zeit und Ressourcen hat um ein Programm zu entwickeln) hat der Mensch (inklusive tev) keine echte Chance gegen einen guten Compiler.
Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.
Das hat niemand bestritten, nur sie entsprechen eben nicht der üblichen realen Praxis. Das sind Ausnahmesituationen!
Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".
Das ist eine sehr praxistaugliche Annahme. Nicht jeder von uns hat die Möglichkeit (oder gar die Fähigkeit) sich mit der Erzeugung der von ihm verbrauchten elektrischen Energie zu befassen. Aber genau darum geht es doch hier. Wie praxistauglich ist es denn ein großes Programm komplett in Assembler zu entwickeln? In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!
Ansonsten möchte ich mich der Aussage von taljeth anschließen.
Grüße
Erik
-
In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!
Bis dahin ist auch die Prozessorgeneration für die die Optimierung gedacht war längst obsolet. :mrgreen:
-
Wo hab ich das getan? Beweise!
Um mal alles auf die Goldwaage zu legen, indem du schon forderst das ein Hochsprachen-Programmierer gut sein muss und der Compiler aktuell sein muss, stellst du doch schon Nebenbedingungen. Genauso wie ich ;)
Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!
Naja, also spielt die Zeit die jemand in Assembler dazu brauchen würde keine Rolle. Das Problem des Hochsprachen-Programmierers ist halt das er auch an die Fähigkeiten des Compilers gebunden ist (ansonsten ist der Vergleich wieder hinfällig, weil wenn er den Compiler verbessert, ist es ja wieder das selbe als wenn er gleich Assemblercode geschrieben hätte), sprich er wüsste zwar wie man den Code noch schneller machen kann, aber die Sprache lässt es nicht zu.
Das ist eine sehr praxistaugliche Annahme.
D.h. du kannst also sagen das ein Auto welches mit Strom fährt grundsätzlich weniger Energie verbraucht als ein Auto was mit Benzin/Diesel fährt? Da es dir egal ist wo der Strom herkommt, kann das ja auch ein absolut altes schlechtes (vom Wirkungsgrad her) Kraftwerk sein.
Am besten finde ich diese Aussage immer wenn es um neue Kraftwerke geht, der Strom soll billig sein und niemand will ein Kraftwerk in seiner Nähe haben (gilt so auch für Windräder). Wie soll dann der Strom aus der Steckdose kommen? Von den anderen Ländern, die dann wieder die bösen bösen Atomkraftwerke dafür nutzen?
In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!
Das kann durchaus sein, aber für den "alten" Computer wird es dann wohl noch richtig sein ;)
Zumal jeder Praxistauglich anders definiert. Ich meine der eine möchte in 2 Jahren ein bestimmtes Ergebnis sehen und der andere will einfach nur Spaß haben und was dabei lernen. Praxistauglich kann auch heißen das es einfach nur möglich ist.
Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.
Aber würdest du nicht schon ewig brauchen um es dann zu verschlüsseln? Irgendwann wird es bestimmt mal möglich sein (selbst wenn das in unendlich vielen Jahren der Fall sein sollte ;) ).
-
Wo hab ich das getan? Beweise!
Um mal alles auf die Goldwaage zu legen, indem du schon forderst das ein Hochsprachen-Programmierer gut sein muss und der Compiler aktuell sein muss, stellst du doch schon Nebenbedingungen. Genauso wie ich ;)
Das sind lediglich Bedingungen für einen fairen Vergleich, und hat mit Realität zurecht biegen nichts zu tun.
Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!
Naja, also spielt die Zeit die jemand in Assembler dazu brauchen würde keine Rolle. Das Problem des Hochsprachen-Programmierers ist halt das er auch an die Fähigkeiten des Compilers gebunden ist (ansonsten ist der Vergleich wieder hinfällig, weil wenn er den Compiler verbessert, ist es ja wieder das selbe als wenn er gleich Assemblercode geschrieben hätte), sprich er wüsste zwar wie man den Code noch schneller machen kann, aber die Sprache lässt es nicht zu.
Der Punkt ist, dass der Compiler von zisch Experten Entwickelt wird, die sich mit nichts anderem Beschäftigen. Und das du vor Intel/AMD weißt wie man ihre Prozessoren Optimal ausnutzt ist ja wohl absurd.
Zumal jeder Praxistauglich anders definiert. Ich meine der eine möchte in 2 Jahren ein bestimmtes Ergebnis sehen und der andere will einfach nur Spaß haben und was dabei lernen. Praxistauglich kann auch heißen das es einfach nur möglich ist.
Wer Spaß haben will und nicht an Resultaten interessiert ist, führt nicht Optimierung als Argument an.
Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.
Aber würdest du nicht schon ewig brauchen um es dann zu verschlüsseln? Irgendwann wird es bestimmt mal möglich sein (selbst wenn das in unendlich vielen Jahren der Fall sein sollte ;) ).
Nein mein Aufwand ist Konstant N, deiner 2N. Und ja, theoretisch ist es möglich das in endlicher Zeit zu lösen, nur -- und da sind wir wieder beim Punkt -- du hast nicht genug Zeit.
-
Nein mein Aufwand ist Konstant N, deiner 2N. Und ja, theoretisch ist es möglich das in endlicher Zeit zu lösen, nur -- und da sind wir wieder beim Punkt -- du hast nicht genug Zeit.
Um mal noch mehr Offtopic zu werden: Beweise mir, dass sein Aufwand 2N ist! :-D
-
Boah seid ihr alle toll. Da bin ich mal nicht da und schon werden meine Worte durch den Fleischwolf gedreht.
Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest.
Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.
Diese Aussagen enthalten implizit Randbedingungen, die hier oft genug erwähnt wurden:
(a) Unser aller Lebenszeit ist begrenzt. Ich glaube, daran zweifelt keiner. Das heißt, dass theoretisch konvergierende Beweise für Zeiten von, sagen wir mal, irgendwas größer 80 Jahren praktisch nicht als konvergent angenehmen werden dürfen.
Ja, es ist theoretisch möglich. Dauert es theoretisch länger als ~80 Jahre, kann es mir egal sein, weil dann bin ich tot.
(b.1) Ich gehe stillschweigend davon aus, dass Leute, die Compiler entwickeln, die Architektur des Pentium IV besser kennen als tev. Das gilt damit auch für den Compiler.
(b.2) Ich gehe ferner stillschweigend davon aus, dass tev nicht die Zeit investieren wird, um die Architektur annähernd genausogut zu kennenzulernen.
Daraus folgt:
(b) Der Compiler kennt die Architektur besser als tev es je könnte.
Sicherlich kann er die Zeit investieren. Sicherlich kann er sich die Arbeit machen. Ich bin davon überzeugt, er wird es nicht tun.
Und der Name spielt in den Aussagen überhaupt keine Rolle. Es gibt nur ganz, ganz, ganz wenige Leute, denen ich so eine Arbeit zutrauen würde. Und das sind sicherlich nicht die Leute, die Fragen, ob Assembler sinnvoll ist...
(c) Wenn ich mir Projekte wie SymbOS anschaue, dann staune ich immer wieder über die Ergebnisse, die man mit Assembler so produzieren kann. Gebe ich zu.
Aber: Warum gab es sowas nicht, als die Systeme neu waren? Weil die Programmiertechniken noch nicht existierten.
@FlashBurn: Das heißt umgekehrt, dass du heutige Compiler gegen heutige Assemblerprogrammierer antreten lassen musst und alte Compiler gegen Assemblerprogrammierer aus der damaligen Zeit.
(d) Ist ein Pentium IV ungleich komplexer als ein ganzes, auf dem Z80 basierendes System.
(e) Ist Wissen nicht dasselbe wie Intelligenz. Und wie auch schon gezeigt wurde, ist ein Gehirn auch nur ein Computer. Streng genommen ist er sogar deterministisch. Und wenn man sich neuronale Netze und ähnliche selbstlernende Algorithmen anschaut, stellt sich die Frage, ob Computer nun prinzipiell nicht lernen könnten oder sie es einfach mit heutigen Programmiertechniken nicht tun.
Definiere 'Intelligenz' und 'Lernen'. Vergleiche dies bitte mit dem Aufbau des menschlichen Gehirns.
*seufz*
-
Da ist man ein Tag nicht zu Hause, schon muss man wieder ein haufen Zeug lesen :-P
Aber zur Zeit, die aufgewendet werden muss,um zu optimieren, es müssen nur einige Codestellen (die halt im laufenden Betrieb des Kernels sehr oft genutzt werden) gut optimiert werden. Wenn ich irgendwelche Debugmeldungen(die einmal ausgeführt werden)ausgegeben werden und die schlechter optimiert sind als es ein Compiler macht, dann ist mir das egal.
Und der wichtigere Grund für mich warum ich meinen Kernel in Assembler schreib ist, dass ich lieber in Assembler programmiere als in C.
Wenn ich in C Code schreibe, dann ist mein Code bestimmt weniger effektiv als wenn taljeth oder sonst jemand ihn schreibt, weil es eben viele Sachen gibt mit denen ich mich nicht anfreunden kann, wie beispielsweise die schon beschriebenen Castings, die ich recht nervig finde. So etwas entfällt in Assembler vollkommen und da fühle ich mich wohl :-D.
Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert :-D, wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.
gruß tev
-
wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.
1. Syscall/sysenter reduzieren die kosten in dem Punkt sehr stark.
2. Ich kenne den L4 jetzt nicht, aber ein Klassischer Mikro-Kernel hat den Nachteil von noch viel teureren Kontext wechseln, wegen der vielen Server.
Um mal noch mehr Offtopic zu werden: Beweise mir, dass sein Aufwand 2N ist! :-D
Ne, also da hättest du in der Schule besser aufpassen sollen. xD
-
MNemo ich verwende ja Sysenter, aber daran hab ich gar nicht gedacht als ich meinen letzten Post geschrieben habe. Und zu 2. L4 versucht so wenig Kontextwechsel wie möglich zu erreichen und das bei möglichst wenig Kontext.
-
Nur noch eine Sache, dann lassen wir die Sache hier ruhen ;)
und alte Compiler gegen Assemblerprogrammierer aus der damaligen Zeit.
Ganz ehrlich, das würde ich als einen eher unfairen Vergleich für die Compiler sehen. Ich denke mal damals waren die Assemblerprogrammierer fähiger (ich will niemandem etwas unterstellen) und vorallem zahlreicher und die Compiler waren bei weitem noch nicht so gut wie heute.
back2topic
Gerade der L4 hängt stark von der IPC Performance ab, da er eigentlich sogar verdammt viele Kontextwechsel haben müsste. Da wird sogar um eine Page zu mappen IPC genutzt.
-
Hallo,
Das ist eine sehr praxistaugliche Annahme.
D.h. du kannst also sagen das ein Auto welches mit Strom fährt grundsätzlich weniger Energie verbraucht als ein Auto was mit Benzin/Diesel fährt? Da es dir egal ist wo der Strom herkommt, kann das ja auch ein absolut altes schlechtes (vom Wirkungsgrad her) Kraftwerk sein.
Am besten finde ich diese Aussage immer wenn es um neue Kraftwerke geht, der Strom soll billig sein und niemand will ein Kraftwerk in seiner Nähe haben (gilt so auch für Windräder). Wie soll dann der Strom aus der Steckdose kommen? Von den anderen Ländern, die dann wieder die bösen bösen Atomkraftwerke dafür nutzen?
Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau! Ich bin hier wohl der einzigste der tatsächlich Verantwortung für die nächste Generation trägt und da brauche ich mir von niemanden erklären zu lassen wie wir unseren Planeten behandeln sollten. Über die Art wie der Strom, der bei mir ganz einfach aus der Steckdose kommt, erzeugt werden soll habe ich gut nachgedacht als ich mein Kreuzchen auf dem Wahlzettel positioniert habe. Viel mehr kann ich kaum machen oder soll ich jetzt zum Demonstrationstourismusbüro gehen und mir eine Teilname bei der nächsten Castor-Demo buchen und mich dort an die Gleise ketten (und mein Kleiner kann sich dann seine Erziehung im Knast abholen)?
Ich bin ziemlich enttäuscht, FlashBurn.
Praxistauglich kann auch heißen das es einfach nur möglich ist.
Nein, praxistauglich ist nur das was auch in der realen Praxis tatsächlich funktioniert. Wenn ich für die Lösung einer Aufgabe >100 Jahre benötige dann ist das einfach nicht praxistauglich egal ob ich prinzipiell fähig bin oder nicht.
.... lassen wir die Sache hier ruhen
Das wäre sehr zu Deinem Vorteil!
Da ist man ein Tag nicht zu Hause, schon muss man wieder ein haufen Zeug lesen :-P
So ist das eben wenn man einen lustigen Flame-War (unbeabsichtigt) lostritt. ;)
So etwas entfällt in Assembler vollkommen und da fühle ich mich wohl :-D.
So habe ich auch mal gedacht als ich noch jung war, bis ich dann die Vorzüge strenger Typisierung (und da ist C noch ziemlich relaxt, da gibt es ganz andere Programmiersprachen die das deutlich korrekter nehmen) und gut lesbarer + ausdrucksstarker Syntax kennen gelernt habe. Heute nehme ich Assembler nur noch wenn ich muss oder wenn ich mir einfach mal den Spaß meiner Jugend noch mal gönnen möchte.
Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert :-D, wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.
Desto weniger Funktionalität im Kernel selber ist desto mehr benötigen die User-Mode-Prozesse das IPC und entsprechend häufiger kommen dann die Kontext-Wechsel. Das ist ja der Grund warum nahezu alle erfolgreichen Microkernel-OSe schon längst keine echten Microkernel mehr sind (Mac OS X und Windows sind da nur die prominentesten Vertreter) und das nur weil sie es eben nicht geschafft haben den IPC-Overhead auf ein akzeptables Maß zu reduzieren. Überlege Dir lieber wie das IPC-Konzept möglichst effizient werden kann, also auf algorithmischer Ebene (hier ist nämlich die menschliche Kreativität tatsächlich erforderlich und hier lassen sich auch die viel größeren Performancesteigerungen erzielen), und überlasse das umsetzen in Maschinen-Code dem Compiler. Betrachte den Compiler als Teil Deines Teams, Du machst den algorithmischen/kreativen Part und der Compiler macht die Drecksarbeit, so kann tatsächlich ein wirklich gutes Ergebnis bei raus kommen. Und ganz wichtig, Performance ist nicht alles, auch die Absturzhäufigkeit ist ein wichtiges Kriterium für/gegen ein OS. Was nützt mir ein OS das zwar theoretisch o,5% schneller ist aber bereits abstürzt bevor ich mein Tageswerk erledigt habe. Assembler-Code nicht nur hochperformant sondern auch übersichtlich und wartbar zu gestalten ist schon eine ziemlich hohe Kunst (was nicht heißen soll dass das unmöglich ist) die umso schwieriger wird desto mehr Code Du hast.
Grüße
Erik
-
Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau!
Ich habe nur aus deinem gesagten etwas anderes geschlossen! Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt, dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.
-
Hey was soll das, Du legst mir da Worte/Aussagen in den Mund die niemals von mir kommen würden. Das ist absolut unterstes Niveau!
Ich habe nur aus deinem gesagten etwas anderes geschlossen! Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt, dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.
Dein Schluss aus Eriks Meinung ist aber auch nicht korrekt ;).
Eriks These mag stimmen, das bedeutet aber nicht, dass er auch der Meinung ist. Du ziehst falsche Rückschlüsse, denn bloß weil man sich nicht von einer Aussage/Meinung distanziert, bedeutet das nicht, dass man sie unterstützt.
-
Und noch einmal zum Kernel selber. Im Endeffekt reicht es wenn der Kernel nach außen hin Funktionen für das IPC (natürlich gut implementiert :-D, wobei das wahrscheinlich bei mir nicht beim ersten Anlauf so sein wird) bereit stellt, weil der Rest kann im Userspace erledigt werden und wenn weniger der Kernel aufgerufen wird, dann gibt es weniger, Performance kostende Ringwechsel.
Desto weniger Funktionalität im Kernel selber ist desto mehr benötigen die User-Mode-Prozesse das IPC und entsprechend häufiger kommen dann die Kontext-Wechsel. Das ist ja der Grund warum nahezu alle erfolgreichen Microkernel-OSe schon längst keine echten Microkernel mehr sind (Mac OS X und Windows sind da nur die prominentesten Vertreter) und das nur weil sie es eben nicht geschafft haben den IPC-Overhead auf ein akzeptables Maß zu reduzieren. Überlege Dir lieber wie das IPC-Konzept möglichst effizient werden kann, also auf algorithmischer Ebene (hier ist nämlich die menschliche Kreativität tatsächlich erforderlich und hier lassen sich auch die viel größeren Performancesteigerungen erzielen), und überlasse das umsetzen in Maschinen-Code dem Compiler. Betrachte den Compiler als Teil Deines Teams, Du machst den algorithmischen/kreativen Part und der Compiler macht die Drecksarbeit, so kann tatsächlich ein wirklich gutes Ergebnis bei raus kommen. Und ganz wichtig, Performance ist nicht alles, auch die Absturzhäufigkeit ist ein wichtiges Kriterium für/gegen ein OS. Was nützt mir ein OS das zwar theoretisch o,5% schneller ist aber bereits abstürzt bevor ich mein Tageswerk erledigt habe. Assembler-Code nicht nur hochperformant sondern auch übersichtlich und wartbar zu gestalten ist schon eine ziemlich hohe Kunst (was nicht heißen soll dass das unmöglich ist) die umso schwieriger wird desto mehr Code Du hast.
Genau bei der Geschwindigkeit setzt L4 ja an, deswegen kann man L4 auch als Mikrokernel der 2. Generation bezeichnen.Aber bevor ich hier einen endlosen Text schreib :wink: gibt es hier ein genaueres Konzept findet man hier http://www.lowlevel.eu/w/images/2/29/Die_L4-Mikrokernel-Familie.pdf (http://www.lowlevel.eu/w/images/2/29/Die_L4-Mikrokernel-Familie.pdf).
Und zur Sprachenwahl; Das steht für mich außer Diskussion, das ist mein Entschluss mit dem ich leben muss :-D. Das heißt aber nicht, dass es objektiv die beste Wahl ist; Lediglich subjektiv.
-
Hallo,
Wenn du sagst das es durchaus gängige Praxis ist, das man sich nicht darum kümmert wo der Strom herkommt
Also:Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".
Das ist eine sehr praxistaugliche Annahme.
Mit "sehr praxistaugliche Annahme" habe ich den Inhalt Deiner These nicht bewertet, ich habe nur zum Ausdruck bringen wollen das es in der Praxis (also jedes mal wenn man ein elektrisches Gerät einschaltet) sehr tauglich ist wenn man den Strom aus der Steckdose so akzeptiert wie er ist. Es bringt absolut nichts jedes mal darüber zu philosophieren wo den nun der Strom am besten her kommen sollte, da käme man (hier im technisierten Mitteleuropa) ja nicht mehr zum eigentlichen Leben. Ich hoffe das jeder hier die Möglichkeiten die sich real bieten auf unseren Strom Einfluss zu nehmen auch nutzt, also bei Wahlen und auch mal bei friedlichen (wohnortnahen) Demonstrationen. Aber wenn ich einen Stecker in den Steckdose stecken muss weil ich den Staubsauger benutzen will dann bringt es eben absolut nichts sich über den Strom überhaupt Gedanken zu machen. Genau das meine ich mit "praxistauglich". Damit will ich keinesfalls zum Ausdruck bringen das man sich gar nicht darum kümmern sollte wo der Strom her kommt.
dann kann ich davon ausgehen, dass das auch deine Meinung ist! Wenn dem nicht so ist, musst du das schon sagen.
Ich habe mir Deine These nirgends zu eigen gemacht noch habe ich diese inhaltlich bewertet, also kannst Du absolut gar nichts über meine persönliche Meinung spekulieren. Natürlich möchte ich das der Strom möglichst sauber erzeugt wird und ich dafür möglichst wenig Geld bezahlen muss aber diese Gedanken mache ich mir wenn es sich auch wirklich lohnt und das ist in der täglichen Lebens-Praxis (leider) nur sehr selten der Fall. Genau daraus ergibt sich die Schlussfolgerung das es recht praxistauglich ist den Strom aus der Steckdose einfach so zu akzeptieren wie er ist, nicht mehr und nicht weniger.
Genau bei der Geschwindigkeit setzt L4 ja an, deswegen kann man L4 auch als Mikrokernel der 2. Generation bezeichnen.
Aber gerade die Mechanismen die vom L4 eingesetzt werden halte ich persönlich nur für bedingt geeignet dieses Ziel zu erreichen. Der L4 ist ganz sicher ein sehr guter Schritt in die richtige Richtung aber ein "gelungenes Endergebnis" stellt er in meinen Augen noch nicht dar. Nebst dessen das der extreme Minimalismus des L4 eben auch wieder einen sehr hohen IPC-Trafic erzeugt (viel Kleinvieh macht auch viel Mist).
Und zur Sprachenwahl; Das steht für mich außer Diskussion, das ist mein Entschluss mit dem ich leben muss :-D. Das heißt aber nicht, dass es objektiv die beste Wahl ist; Lediglich subjektiv.
Gut, damit kann ich sehr gut leben. Das ist Deine freie Entscheidung und ich hoffe das Du damit so viel Spaß wie möglich hast und natürlich auch Erfolg.
Grüße
Erik
-
Auch wenn es jetzt eigentlich nicht hierher gehört, aber ich bin eigentlich schon davon ausgegangen das wenn man sich von einer Meinung nicht distanziert, das man dann der Meinung ist. Bzw. in diesem Fall klang es für mich als wenn erik der Meinung zustimmt.
@tev
Lass dich von Assembler nicht abbringen. Man kann viel dabei lernen. Zumal ein L4 Kernel ja eigentlich nicht so groß werden dürfte, der macht ja kaum was ;)
-
Lass dich von Assembler nicht abbringen. Man kann viel dabei lernen. Zumal ein L4 Kernel ja eigentlich nicht so groß werden dürfte, der macht ja kaum was ;)
Denk ich mir doch ;)
Später will ich wahrscheinlich noch eine libc und so portieren, damit auch andere ihren Spaße haben können :-D
-
Hallo,
aber ich bin eigentlich schon davon ausgegangen das wenn man sich von einer Meinung nicht distanziert, das man dann der Meinung ist.
Daran werde ich Dich bei Gelegenheit erinnern. Okay?
Bzw. in diesem Fall klang es für mich als wenn erik der Meinung zustimmt.
Wirklich? Ich habe doch erklärt warum ich Deine These für eine praxistaugliche Annahme halte, aber ohne diese zu bewerten (erst recht nicht positiv). Und auch danach hab ich ziemlich auf dem Wort "praxistauglich" rumgeritten. Ich bin davon ausgegangen das jeder versteht das es mir um die Praxistauglichkeit als solches geht und es zusätzlich (fälschlicherweise) implizit als logisch vorausgesetzt das es eben nicht praxistauglich ist sich ständig Gedanken über die Herkunft der elektrischen Energie zu machen die man aus der Steckdose konsumiert. Schließlich hat sich doch fast der ganze Thread um die Praxistauglichkeit von Thesen gedreht.
Ich würde es im übrigen auch als sehr praxistauglich erachten wenn wir uns alle in Zukunft nicht mehr ganz so arg (oder wenigsten mit etwas mehr praktiziertem Respekt) über Kleinigkeiten auslassen könnten.
praktische Grüße
Erik